Vulnerabilities

Stirling-PDF is a locally hosted web application that performs various operations on PDF files. In versions prior to 2.5.2, the /api/v1/convert/markdown/pdf endpoint extracts user-supplied ZIP entries without path checks. Any authenticated user can write files outside the intended temporary working directory, leading to arbitrary file write with the privileges of the Stirling-PDF process user (stirlingpdfuser). This can overwrite writable files and compromise data integrity, with further impact depending on writable paths. The issue was fixed in version 2.5.2.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: add xmit recursion limit to tunnel xmit functions<br /> <br /> Tunnel xmit functions (iptunnel_xmit, ip6tunnel_xmit) lack their own<br /> recursion limit. When a bond device in broadcast mode has GRE tap<br /> interfaces as slaves, and those GRE tunnels route back through the<br /> bond, multicast/broadcast traffic triggers infinite recursion between<br /> bond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), causing<br /> kernel stack overflow.<br /> <br /> The existing XMIT_RECURSION_LIMIT (8) in the no-qdisc path is not<br /> sufficient because tunnel recursion involves route lookups and full IP<br /> output, consuming much more stack per level. Use a lower limit of 4<br /> (IP_TUNNEL_RECURSION_LIMIT) to prevent overflow.<br /> <br /> Add recursion detection using dev_xmit_recursion helpers directly in<br /> iptunnel_xmit() and ip6tunnel_xmit() to cover all IPv4/IPv6 tunnel<br /> paths including UDP encapsulated tunnels (VXLAN, Geneve, etc.).<br /> <br /> Move dev_xmit_recursion helpers from net/core/dev.h to public header<br /> include/linux/netdevice.h so they can be used by tunnel code.<br /> <br /> BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160<br /> Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11<br /> Workqueue: mld mld_ifc_work<br /> Call Trace:<br /> <br /> __build_flow_key.constprop.0 (net/ipv4/route.c:515)<br /> ip_rt_update_pmtu (net/ipv4/route.c:1073)<br /> iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84)<br /> ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)<br /> gre_tap_xmit (net/ipv4/ip_gre.c:779)<br /> dev_hard_start_xmit (net/core/dev.c:3887)<br /> sch_direct_xmit (net/sched/sch_generic.c:347)<br /> __dev_queue_xmit (net/core/dev.c:4802)<br /> bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)<br /> bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)<br /> bond_start_xmit (drivers/net/bonding/bond_main.c:5530)<br /> dev_hard_start_xmit (net/core/dev.c:3887)<br /> __dev_queue_xmit (net/core/dev.c:4841)<br /> ip_finish_output2 (net/ipv4/ip_output.c:237)<br /> ip_output (net/ipv4/ip_output.c:438)<br /> iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86)<br /> gre_tap_xmit (net/ipv4/ip_gre.c:779)<br /> dev_hard_start_xmit (net/core/dev.c:3887)<br /> sch_direct_xmit (net/sched/sch_generic.c:347)<br /> __dev_queue_xmit (net/core/dev.c:4802)<br /> bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)<br /> bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)<br /> bond_start_xmit (drivers/net/bonding/bond_main.c:5530)<br /> dev_hard_start_xmit (net/core/dev.c:3887)<br /> __dev_queue_xmit (net/core/dev.c:4841)<br /> ip_finish_output2 (net/ipv4/ip_output.c:237)<br /> ip_output (net/ipv4/ip_output.c:438)<br /> iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86)<br /> ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)<br /> gre_tap_xmit (net/ipv4/ip_gre.c:779)<br /> dev_hard_start_xmit (net/core/dev.c:3887)<br /> sch_direct_xmit (net/sched/sch_generic.c:347)<br /> __dev_queue_xmit (net/core/dev.c:4802)<br /> bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)<br /> bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)<br /> bond_start_xmit (drivers/net/bonding/bond_main.c:5530)<br /> dev_hard_start_xmit (net/core/dev.c:3887)<br /> __dev_queue_xmit (net/core/dev.c:4841)<br /> mld_sendpack<br /> mld_ifc_work<br /> process_one_work<br /> worker_thread<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels<br /> <br /> IDLETIMER revision 0 rules reuse existing timers by label and always call<br /> mod_timer() on timer-&gt;timer.<br /> <br /> If the label was created first by revision 1 with XT_IDLETIMER_ALARM,<br /> the object uses alarm timer semantics and timer-&gt;timer is never initialized.<br /> Reusing that object from revision 0 causes mod_timer() on an uninitialized<br /> timer_list, triggering debugobjects warnings and possible panic when<br /> panic_on_warn=1.<br /> <br /> Fix this by rejecting revision 0 rule insertion when an existing timer with<br /> the same label is of ALARM type.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit<br /> <br /> teql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit<br /> through slave devices, but does not update skb-&gt;dev to the slave device<br /> beforehand.<br /> <br /> When a gretap tunnel is a TEQL slave, the transmit path reaches<br /> iptunnel_xmit() which saves dev = skb-&gt;dev (still pointing to teql0<br /> master) and later calls iptunnel_xmit_stats(dev, pkt_len). This<br /> function does:<br /> <br /> get_cpu_ptr(dev-&gt;tstats)<br /> <br /> Since teql_master_setup() does not set dev-&gt;pcpu_stat_type to<br /> NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats<br /> for teql0, so dev-&gt;tstats is NULL. get_cpu_ptr(NULL) computes<br /> NULL + __per_cpu_offset[cpu], resulting in a page fault.<br /> <br /> BUG: unable to handle page fault for address: ffff8880e6659018<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 68bc067 P4D 68bc067 PUD 0<br /> Oops: Oops: 0002 [#1] SMP KASAN PTI<br /> RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89)<br /> Call Trace:<br /> <br /> ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)<br /> __gre_xmit (net/ipv4/ip_gre.c:478)<br /> gre_tap_xmit (net/ipv4/ip_gre.c:779)<br /> teql_master_xmit (net/sched/sch_teql.c:319)<br /> dev_hard_start_xmit (net/core/dev.c:3887)<br /> sch_direct_xmit (net/sched/sch_generic.c:347)<br /> __dev_queue_xmit (net/core/dev.c:4802)<br /> neigh_direct_output (net/core/neighbour.c:1660)<br /> ip_finish_output2 (net/ipv4/ip_output.c:237)<br /> __ip_finish_output.part.0 (net/ipv4/ip_output.c:315)<br /> ip_mc_output (net/ipv4/ip_output.c:369)<br /> ip_send_skb (net/ipv4/ip_output.c:1508)<br /> udp_send_skb (net/ipv4/udp.c:1195)<br /> udp_sendmsg (net/ipv4/udp.c:1485)<br /> inet_sendmsg (net/ipv4/af_inet.c:859)<br /> __sys_sendto (net/socket.c:2206)<br /> <br /> Fix this by setting skb-&gt;dev = slave before calling<br /> netdev_start_xmit(), so that tunnel xmit functions see the correct<br /> slave device with properly allocated tstats.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: unconditionally bump set-&gt;nelems before insertion<br /> <br /> In case that the set is full, a new element gets published then removed<br /> without waiting for the RCU grace period, while RCU reader can be<br /> walking over it already.<br /> <br /> To address this issue, add the element transaction even if set is full,<br /> but toggle the set_full flag to report -ENFILE so the abort path safely<br /> unwinds the set to its previous state.<br /> <br /> As for element updates, decrement set-&gt;nelems to restore it.<br /> <br /> A simpler fix is to call synchronize_rcu() in the error path.<br /> However, with a large batch adding elements to already maxed-out set,<br /> this could cause noticeable slowdown of such batches.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macvlan: observe an RCU grace period in macvlan_common_newlink() error path<br /> <br /> valis reported that a race condition still happens after my prior patch.<br /> <br /> macvlan_common_newlink() might have made @dev visible before<br /> detecting an error, and its caller will directly call free_netdev(dev).<br /> <br /> We must respect an RCU period, either in macvlan or the core networking<br /> stack.<br /> <br /> After adding a temporary mdelay(1000) in macvlan_forward_source_one()<br /> to open the race window, valis repro was:<br /> <br /> ip link add p1 type veth peer p2<br /> ip link set address 00:00:00:00:00:20 dev p1<br /> ip link set up dev p1<br /> ip link set up dev p2<br /> ip link add mv0 link p2 type macvlan mode source<br /> <br /> (ip link add invalid% link p2 type macvlan mode source macaddr add<br /> 00:00:00:00:00:20 &amp;) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4<br /> PING 1.2.3.4 (1.2.3.4): 56 data bytes<br /> RTNETLINK answers: Invalid argument<br /> <br /> BUG: KASAN: slab-use-after-free in macvlan_forward_source<br /> (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)<br /> Read of size 8 at addr ffff888016bb89c0 by task e/175<br /> <br /> CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:123)<br /> print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)<br /> ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)<br /> kasan_report (mm/kasan/report.c:597)<br /> ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)<br /> macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)<br /> ? tasklet_init (kernel/softirq.c:983)<br /> macvlan_handle_frame (drivers/net/macvlan.c:501)<br /> <br /> Allocated by task 169:<br /> kasan_save_stack (mm/kasan/common.c:58)<br /> kasan_save_track (./arch/x86/include/asm/current.h:25<br /> mm/kasan/common.c:70 mm/kasan/common.c:79)<br /> __kasan_kmalloc (mm/kasan/common.c:419)<br /> __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657<br /> mm/slub.c:7140)<br /> alloc_netdev_mqs (net/core/dev.c:12012)<br /> rtnl_create_link (net/core/rtnetlink.c:3648)<br /> rtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957<br /> net/core/rtnetlink.c:4072)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2550)<br /> netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1894)<br /> __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)<br /> __x64_sys_sendto (net/socket.c:2209)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)<br /> <br /> Freed by task 169:<br /> kasan_save_stack (mm/kasan/common.c:58)<br /> kasan_save_track (./arch/x86/include/asm/current.h:25<br /> mm/kasan/common.c:70 mm/kasan/common.c:79)<br /> kasan_save_free_info (mm/kasan/generic.c:587)<br /> __kasan_slab_free (mm/kasan/common.c:287)<br /> kfree (mm/slub.c:6674 mm/slub.c:6882)<br /> rtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957<br /> net/core/rtnetlink.c:4072)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2550)<br /> netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1894)<br /> __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)<br /> __x64_sys_sendto (net/socket.c:2209)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix __perf_event_overflow() vs perf_remove_from_context() race<br /> <br /> Make sure that __perf_event_overflow() runs with IRQs disabled for all<br /> possible callchains. Specifically the software events can end up running<br /> it with only preemption disabled.<br /> <br /> This opens up a race vs perf_event_exit_event() and friends that will go<br /> and free various things the overflow path expects to be present, like<br /> the BPF program.

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.

Free5GC is an open-source Linux Foundation project for 5th generation (5G) mobile core networks. Versions prior to 1.4.2 are vulnerable to procedure panic caused by Nil Pointer Dereference in the /sdm-subscriptions endpoint. A remote attacker can cause the UDM service to panic and crash by sending a crafted POST request to the /sdm-subscriptions endpoint with a malformed URL path containing path traversal sequences (../) and a large JSON payload. The DataChangeNotificationProcedure function in notifier.go attempts to access a nil pointer without proper validation, causing a complete service crash with "runtime error: invalid memory address or nil pointer dereference". Exploitation would result in UDM functionality disruption until recovery by restart. This issue has been fixed in version 1.4.2.

Free5GC is an open-source Linux Foundation project for 5th generation (5G) mobile core networks. Versions prior to 1.4.2<br /> are vulnerable to null byte injection in URL path parameters. A remote attacker can inject null bytes (URL-encoded as %00) into the supi path parameter of the UDM&amp;#39;s Nudm_SubscriberDataManagement API. This causes URL parsing failure in Go&amp;#39;s net/url package with the error "invalid control character in URL", resulting in a 500 Internal Server Error. This null byte injection vulnerability can be exploited for denial of service attacks. When the supi parameter contains null characters, the UDM attempts to construct a URL for UDR that includes these control characters. Go&amp;#39;s URL parser rejects them, causing the request to fail with 500 instead of properly validating input and returning 400 Bad Request. This issue has been fixed in version 1.4.2.

Jexactyl is a customisable game management panel and billing system. Commits after 025e8dbb0daaa04054276bda814d922cf4af58da and before e28edb204e80efab628d1241198ea4f079779cfd inject server-side objects into client-side JavaScript through resources/views/templates/wrapper.blade.php. Using unescaped {!! json_encode(...) !!} without safe encoding flags allows string values to break out of the JavaScript context and be interpreted as HTML/JS by the browser. If any serialized fields contain attacker-controlled content, such as a username, display name, or site config value, a malicious payload will execute arbitrary script for any user viewing the page (stored DOM XSS). This issue has been patched by commit e28edb204e80efab628d1241198ea4f079779cfd.

Mesop is a Python-based UI framework that allows users to build web applications. In versions 1.2.2 and below, an explicit web endpoint inside the ai/ testing module infrastructure directly ingests untrusted Python code strings unconditionally without authentication measures, yielding standard Unrestricted Remote Code Execution. Any individual capable of routing HTTP logic to this server block will gain explicit host-machine command rights. The AI codebase package includes a lightweight debugging Flask server inside ai/sandbox/wsgi_app.py. The /exec-py route accepts base_64 encoded raw string payloads inside the code parameter natively evaluated by a basic POST web request. It saves it rapidly to the operating system logic path and injects it recursively using execute_module(module_path...). This issue has been fixed in version 1.2.3.