Threat database
1,131 threats
Most recently published first
| Severity | CVSS | Threat | Source | Published | Score and star |
|---|---|---|---|---|---|
| High | 7.0 | High7.0GCVE Database The GNU C Library project provides the core libraries for the GNU system and GNU/Linux systems, as well as many other systems that use Linux as the kernel. These libraries provide critical APIs including ISO C11, POSIX.1-2008, BSD, OS-specific APIs and more. These APIs include such foundational facilities as open, read, write, malloc, printf, getaddrinfo, dlopen, pthread_create, crypt, login, exit and more. Security Fix(es): The gettext family of functions in the GNU C Library version 2.0 and later accept LANGUAGE environment variable entries that contain '/' or that are equal to "..", unless the program is setuid or setgid (AT_SECURE). An attacker who can set LANGUAGE in the environment of a program that uses gettext can make it load a message catalog (.mo file) from an arbitrary location in the file system. A crafted .mo file can crash the program through out-of-range offsets, or supply translations whose format directives do not match the arguments passed by the program. That causes undefined behaviour in the printf family of functions and may allow arbitrary code execution with the privileges of the program. The safety of message catalogs relies on them being installed in trusted, read-only locations, and the directory traversal bypasses this. The fix for CVE-2014-0475 rejects ".." path components in locale names passed to setlocale or taken from the LC_ALL, LC_* and LANG environment variables. gettext reads LANGUAGE directly and appends each colon-separated entry to the message catalog directory, so that fix did not cover LANGUAGE. LANGUAGE is only used when the LC_MESSAGES locale is not "C", "C.<encoding>" or "POSIX", so the attacker must also be able to select another installed locale, for example through LANG or LC_ALL. Exploitation also requires that the attacker can place the crafted file in a location readable by the target program, and that the environment crosses a trust boundary without the program running as AT_SECURE. An example is an SSH server that accepts LANGUAGE and LANG from clients through the AcceptEnv directive and restricts an account to a forced command; the attacker may use this to escape the restriction.(CVE-2026-84243) | GCVE Database | ||
| Critical | 9.8 | Critical9.8GCVE Database The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: ipv4: free inet_opt and ireq_opt after an RCU grace period tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the child socket (newinet->inet_opt) without copying it. Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp_check_req(). tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt() and ip_options_build() then read opt->optlen twice. Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inet_csk_reqsk_queue_drop() calls timer_delete_sync() before the child can be freed. Since commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt with a plain kfree(), leading to a use-after-free in ip_options_build(). A similar issue exists with request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program). reqsk_timer_handler() clones the request socket with inet_reqsk_clone(), so that the old request socket and its clone share the same ireq_opt, then reqsk_migrate_reset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcp_v4_syn_recv_sock()) when the clone is freed, and tcp_v4_reqsk_destructor() also uses a plain kfree(). Readers already use RCU, and other paths replacing inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor() as well. IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock() duplicates the options. tcp_v6_reqsk_destructor() has the same migration issue with ipv6_opt, which is only set by CALIPSO. This will be addressed in a separate patch.(CVE-2026-98432) | GCVE Database | ||
| Critical | 9.8 | Critical9.8GCVE Database The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size.(CVE-2026-31661) In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Validate GPIO pin LUT table size before iterating [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)(CVE-2026-64097) In the Linux kernel, the following vulnerability has been resolved: usbip: vudc: fix NULL deref in vep_dequeue() vep_alloc_request() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vep_dequeue without a valid UDC reference. Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vep_dequeue to obtain a reference to the udc with ep_to_vudc(), consistent with the other vep_ ops. AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc. I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running `usbip attach` from the host would cause the guest to oops with the following backtrace: Call trace: vep_dequeue+0x1c/0xe4 (P) usb_ep_dequeue+0x14/0x20 ffs_aio_cancel+0x24/0x34 __arm64_sys_io_cancel+0xb0/0x124 do_el0_svc+0x68/0x100 el0_svc+0x18/0x5c el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x154/0x158(CVE-2026-64331) In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: pin L2CAP connection during netdev registration bnep_add_connection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to register_netdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device. Take a reference to the L2CAP connection while holding the channel lock. Retain it until register_netdev() has taken the parent device reference.(CVE-2026-64408) In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)(CVE-2026-68236) In the Linux kernel, the following vulnerability has been resolved: ipv6: fix Route Information option length validation rt6_route_rcv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one. rinfo->length is the ND option length in units of 8 octets and it *includes* the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively. ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefix_len=128, length=2) or (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace: # RA with a Route Information option (prefix_len=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead. Reject the option lengths RFC 4191 does not allow.(CVE-2026-74598) In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel | GCVE Database | ||
| Medium | 6.8 | Medium6.8GCVE Database FFmpeg is a complete and free Internet live audio and video broadcasting solution for Linux/Unix. It also includes a digital VCR. It can encode in real time in many formats including MPEG1 audio and video, MPEG4, h263, ac3, asf, avi, real, mjpeg, and flash. Security Fix(es): FFmpeg through 9.0.2 contains a stack exhaustion vulnerability in av_encryption_init_info_free() in libavutil/encryption_info.c, which recursively frees AVEncryptionInitInfo linked lists built by the MOV demuxer's mov_read_pssh(). Attackers can supply a crafted MP4 file with tens of thousands of small pssh boxes to exhaust the stack and crash the process, while also causing quadratic CPU consumption.(CVE-2026-107678) FFmpeg 2.0 through 9.0.2 contains a use of uninitialized variable vulnerability in the Go2Meeting decoder that allows attackers to leak stack memory through out-of-range palette indices. Attackers can craft a G2M3/G2M4 stream with a short Kempf palette so kempf_restore_buf() copies uninitialized stack bytes, including pointers or stack guards, into decoded output.(CVE-2026-120243) FFmpeg 2.1 through 9.0.2 contains a use of uninitialized resource vulnerability in the PCX decoder that allows attackers to leak heap memory through truncated RLE scanlines. Attackers can craft a PCX image whose RLE data ends early, causing pcx_decode_frame() to copy uninitialized av_malloc() buffer contents into visible decoded pixels.(CVE-2026-120244) FFmpeg 0.10 through 9.0.2 contains a use of uninitialized resource vulnerability in sunrast_decode_frame() that leaks heap memory when decoding truncated 1-bit and 4-bit paletted Sun Raster images. Attackers can craft a truncated Sun Raster file so the uncleared temporary bitmap is expanded into PAL8 pixels, exposing stale heap contents such as allocator words in decoded output.(CVE-2026-120245) FFmpeg 4.4 through 9.0.2 contains a use of uninitialized variable vulnerability in the CDXL decoder that leaks stack memory into decoded pixels via unfilled HAM palette entries. Attackers can craft a type-0 CDXL file whose HAM pixels select unfilled new_palette entries in cdxl_decode_ham8() or cdxl_decode_ham6(), exposing stack bytes and pointer fragments in the BGR24 output.(CVE-2026-120246) FFmpeg 2.3 through 9.0.2 contains a use of uninitialized resource vulnerability in the Huffyuv decoder that allows attackers to leak heap memory into decoded pixels via short packed-BGR bitstreams. Attackers can craft a Huffyuv BGR24/BGRA video whose entropy data ends early, causing decode_slice() to add uninitialized s->temp[0] bytes into output frames, exposing heap contents.(CVE-2026-120247) | GCVE Database | ||
| High | 7.8 | High7.8GCVE Database The RPM Package Manager (RPM) is a powerful package management system capability as below Security Fix(es): A flaw was found in rpm. An attacker can supply a crafted manifest file that, when processed by a user or automation using `rpm -q -p` or similar manifest-processing flows, leads to arbitrary code execution. This occurs because manifest entries are unexpectedly macro-expanded before being opened, allowing embedded shell commands to run with the privileges of the `rpm` process. Successful exploitation can lead to a full compromise of confidentiality, integrity, and availability for the affected account.(CVE-2026-95519) | GCVE Database | ||
| High | 7.1 | High7.1GCVE Database The RPM Package Manager (RPM) is a powerful package management system capability as below Security Fix(es): A heap-based buffer overflow flaw was found in rpm. RPMTAG_FILESIGNATURES in a crafted, unsigned RPM package's main header is declared with the wrong header type, causing hex2binv() to allocate a one-byte buffer and then write the tag's attacker-controlled, hex-decoded content — of attacker-chosen length — past the end of that allocation. This is reachable via rpm2cpio, rpm2archive, and rpm -qlvp on an untrusted package.(CVE-2026-103242) A flaw was found in rpm. An attacker can supply a crafted manifest file that, when processed by a user or automation using `rpm -q -p` or similar manifest-processing flows, leads to arbitrary code execution. This occurs because manifest entries are unexpectedly macro-expanded before being opened, allowing embedded shell commands to run with the privileges of the `rpm` process. Successful exploitation can lead to a full compromise of confidentiality, integrity, and availability for the affected account.(CVE-2026-95519) | GCVE Database | ||
| High | 7.8 | High7.8GCVE Database Xwayland is an X server for running X clients under Wayland. %package devel Summary: Development package Requires: pkgconfig %description devel The development package provides the developmental files which are necessary for developing Wayland compositors using Xwayland. %prep %autosetup -n xwayland- -p1 %build %meson \ -Ddefault_font_path=&quot;catalogue:/etc/X11/fontpath.d,built-ins&quot; \ -Dbuilder_string=&quot;Build ID: -&quot; \ -Dxkb_output_dir=/lib/xkb \ -Dxcsecurity=true \ -Dglamor=true \ -Ddri3=true %meson_build Security Fix(es): ['Hi all,\n\nCVEs have been issued now, please see inline below\n\nOn Tue, Jun 02, 2026 at 10:01:46AM +1000, Peter Hutterer wrote:', "=======================================================================\nX.Org Security Advisory: June 2, 2026 \n\nIssues in X.Org X server prior to 21.1.23 and Xwayland prior to 24.1.12\n=======================================================================\n\nMultiple issues have been found in the X server and Xwayland implementations\npublished by X.Org for which we are releasing security fixes for in\nxorg-server-21.1.23 and xwayland-24.1.12.\n\nNote that CVEs have been requested for these issues but did not get assigned in\ntime for this disclosure.\n\n* Font Alias Stack-based Buffer Overflow\n\n A mismatch between the X server and the libXfont2 library's maximum\n font name length can cause a stack buffer overflow during font alias\n resolution. The server allocates a 256 byte stack buffer but libXfont2's\n alias target name length is 1024 bytes. A font alias name between 257\n and 1023 bytes causes the X server to copy that name into the undersized\n stack buffer without further checks.\n\n Fixed in: xorg-server-21.1.23 and xwayland-24.1.12\n Fix:", 'Found by: Anonymous working with TrendAI Zero Day Initiative.\n (ZDI-CAN-30136)', 'This issue has been assigned CVE-2026-50256', '* XSYNC Use-After-Free in miSyncDestroyFence()\n\n A client that sets up multiple fence triggers can trigger a\n use-after-free function pointer call. An attacker would connect to the\n X server to set up a fence and await that fence, then a second X\n connection destroys the fence, causing the use-after-free.\n\n Fixed in: xorg-server-21.1.23 and xwayland-24.1.12\n Fix:', 'Found by: Anonymous working with TrendAI Zero Day Initiative.\n (ZDI-CAN-30159)', 'This issue has been assigned CVE-2026-50257', '* XKB Key Types Stack-based Buffer Overflow\n\n The X server has multiple stack buffers that are sized\n XkbMaxShiftLevel * XkbNumKbdGroups but CheckKeyTypes() does not verify\n or clamp non-canonical key types to XkbMaxShiftLevel. A client can\n change key types to excessive shift levels and trigger three separate\n stack overflows.\n\n This is caused by an incomplete fix of CVE-2025-26597.\n\n Fixed in: xorg-server-21.1.23 and xwayland-24.1.12\n Fix:', 'Found by: Anonymous working with TrendAI Zero Day Initiative.\n (ZDI-CAN-30160)', 'This issue has been assigned CVE-2026-50258', '* XKB SetMap Request Stack-based Buffer Overflow\n\n _XkbSetMapChecks() declares a fixed-size stack buffer mapWidths[256]\n indexed by key type index. The helper function CheckKeyTypes() writes\n to this buffer at a client-controlled offset, allowing a stack buffer\n overflow.\n\n Fixed in: xorg-server-21.1.23 and xwayland-24.1.12\n Fix:', 'Found by: Anonymous working with TrendAI Zero Day Initiative.\n (ZDI-CAN-30161)', 'This issue has been assigned CVE-2026-50259', '* XSYNC Use-After-Free in FreeCounter()\n\n A client that sets up multiple SyncCounters and awaits on those\n triggers can trigger a use-after-free when destroying those counters\n via a second client connection.\n\n Fixed in: xorg-server-21.1.23 and xwayland-24.1.12\n Fix:', 'Found by: Anonymous working with TrendAI Zero Day Initiative.\n (ZDI-CAN-30163)', 'This issue has been assigned CVE-2026-50260', '* XSYNC Use-After-Free in SyncChangeCounter()\n\n A client that sets up multiple SyncCounters can trigger a use-after-free\n when destroying those counters via a second client connection while\n changing those counters.\n\n Fixed in: xorg-server-21.1.23 and xwayland-24.1.12\n Fix:', 'Found by: Anonymous working with TrendAI Zero Day Initiative.\n (ZDI-CAN-30164)', 'This issue has been assigned CVE-2026-50261', '* GLX ChangeDrawableAttributes Out-Of-Bounds Read/Write\n\n A wrong size validation check in __glXDisp_ChangeDrawableAttributes()\n can read (or write) a client-contr(CVE-2026-50256) | GCVE Database | ||
| Medium | 5.3 | Medium5.3GCVE Database Tornado is a Python web framework and asynchronous networking library, originally developed at FriendFeed. By using non-blocking network I/O, Tornado can scale to tens of thousands of open connections, making it ideal for long polling, WebSockets, and other applications that require a long-lived connection to each user. Security Fix(es): Tornado is a Python web framework and asynchronous networking library. Prior to 6.6.0, Tornado decodes HTTP/1.1 chunked transfer encoding by processing body data that has already arrived without yielding to the event loop. A remote unauthenticated peer can send millions of one-byte chunks to monopolize the process event loop and stall every other connection served by that process, while lowering max_body_size only limits the duration of each request. For handlers that do not use @stream_request_body, retaining each chunk as a separate object can consume roughly twenty times the received body size, and SimpleAsyncHTTPClient has the same event-loop behavior when reading a response from a malicious server. This issue is fixed in version 6.6.0.(CVE-2026-115927) Tornado is a Python web framework and asynchronous networking library. Prior to 6.6, Tornado's HTTP header parser accepts obsolete line folding and repeatedly concatenates short continuation lines, causing quadratic CPU consumption on the IOLoop thread. An unauthenticated client can submit a header block containing many obsolete line-folding continuations before application code runs, blocking other connections served by the process. The cost grows with max_header_size, and only availability is affected. This issue is fixed in version 6.6.(CVE-2026-116577) Tornado is a Python web framework and asynchronous networking library. Prior to 6.6, tornado.web.RedirectHandler URL templates can place regex-capture substitutions where crafted request paths change the redirect scheme or network location. Affected placements include substitutions at the start of a path, directly after a fixed host, or at the beginning of the template, including protocol-relative, absolute, backslash, encoded, host-extension, and user-info variants interpreted by browsers as attacker-controlled destinations. Static templates and substitutions after a fixed host followed by a slash are not affected. An attacker can use the resulting open redirect on the application's domain for phishing. This issue is fixed in version 6.6.(CVE-2026-116578) | GCVE Database | ||
| High | 7.1 | High7.1GCVE Database Qt (pronounced as &quot;cute&quot;, not &quot;cu-tee&quot;) is a cross-platform framework that is usually used as a graphical toolkit, although it is also very helpful in creating CLI applications. It runs on the three major desktop OSes, as well as on mobile OSes, such as Symbian, Nokia Belle, Meego Harmattan, MeeGo or BB10, and on embedded devices. Ports for Android (Necessitas) and iOS are also in development Security Fix(es): Uncontrolled recursion in Qt's QDomDocument serialization (QtXml) lets deeply nested untrusted XML crash the app via stack exhaustion (DoS only).(CVE-2026-11573) | GCVE Database |
Page 9 of 74 · 11 duplicate CVE records merged