Vulnerabilities

A flaw was found in the X.Org X server. This use-after-free vulnerability occurs in the XSYNC fence triggering logic, specifically within the miSyncTriggerFence() function. An attacker with access to the X11 server can exploit this without user interaction, leading to a server crash and potentially enabling memory corruption. This could result in a denial of service or further compromise of the system.

A flaw was found in the X.Org X server's XKB key types request validation. A local attacker could send a specially crafted request to the X server, leading to an out-of-bounds memory access vulnerability. This could result in the disclosure of sensitive information or cause the server to crash, leading to a Denial of Service (DoS). In certain configurations, higher impact outcomes may be possible.

Jizhicms v2.5.4 is vulnerable to SQL injection in the product editing module.

SocialEngine versions 7.8.0 and prior contain a SQL injection vulnerability in the /activity/index/get-memberall endpoint where user-supplied input passed via the text parameter is not sanitized before being incorporated into a SQL query. An unauthenticated remote attacker can exploit this vulnerability to read arbitrary data from the database, reset administrator account passwords, and gain unauthorized access to the Packages Manager in the Admin Panel, potentially enabling remote code execution.

SocialEngine versions 7.8.0 and prior contain a blind server-side request forgery vulnerability in the /core/link/preview endpoint where user-supplied input passed via the uri request parameter is not sanitized before being used to construct outbound HTTP requests. Authenticated remote attackers can supply arbitrary URLs including internal network addresses and loopback addresses to cause the server to issue HTTP requests to attacker-controlled destinations, enabling internal network enumeration and access to services not intended to be externally reachable.

An unauthenticated remote attacker is able to exhaust all available TCP connections in the CODESYS EtherNet/IP adapter stack, preventing legitimate clients from establishing new connections.

Yadea T5 Electric Bicycles (models manufactured in/after 2024) have a weak authentication mechanism in their keyless entry system. The system utilizes the EV1527 fixed-code RF protocol without implementing rolling codes or cryptographic challenge-response mechanisms. This is vulnerable to signal forgery after a local attacker intercepts any legitimate key fob transmission, allowing for complete unauthorized vehicle operation via a replay attack.

Improper Control of Generation of Code ('Code Injection') vulnerability in Funnelforms LLC FunnelFormsPro allows Remote Code Inclusion.This issue affects FunnelFormsPro: from n/a through 3.8.1.

An API design flaw in WebKitGTK and WPE WebKit allows untrusted web content to unexpectedly perform IP connections, DNS lookups, and HTTP requests. Applications expect to use the<br /> WebPage::send-request signal handler to approve or reject all network requests. However, certain types of HTTP requests bypass this signal handler.

Multiple uses of uninitialized variables were found in libopensc that may lead to information disclosure or application crash. An attack requires a crafted USB device or smart card that would present the system with specially crafted responses to the APDUs

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()<br /> <br /> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently<br /> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for<br /> single nexthops and small Equal-Cost Multi-Path groups, this fixed<br /> allocation fails for large nexthop groups like 512 nexthops.<br /> <br /> This results in the following warning splat:<br /> <br /> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608<br /> [...]<br /> RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)<br /> [...]<br /> Call Trace:<br /> <br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)<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_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)<br /> ___sys_sendmsg (net/socket.c:2641)<br /> __sys_sendmsg (net/socket.c:2671)<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:130)<br /> <br /> <br /> Fix this by allocating the size dynamically using nh_nlmsg_size() and<br /> using nlmsg_new(), this is consistent with nexthop_notify() behavior. In<br /> addition, adjust nh_nlmsg_size_grp() so it calculates the size needed<br /> based on flags passed. While at it, also add the size of NHA_FDB for<br /> nexthop group size calculation as it was missing too.<br /> <br /> This cannot be reproduced via iproute2 as the group size is currently<br /> limited and the command fails as follows:<br /> <br /> addattr_l ERROR: message exceeded bound of 1048

Missing Authorization vulnerability in Navneil Naicker ACF Galerie 4 allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects ACF Galerie 4: from n/a through 1.4.2.