| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In ISC BIND9 versions BIND 9.11.14 -> 9.11.19, BIND 9.14.9 -> 9.14.12, BIND 9.16.0 -> 9.16.3, BIND Supported Preview Edition 9.11.14-S1 -> 9.11.19-S1: Unless a nameserver is providing authoritative service for one or more zones and at least one zone contains an empty non-terminal entry containing an asterisk ("*") character, this defect cannot be encountered. A would-be attacker who is allowed to change zone content could theoretically introduce such a record in order to exploit this condition to cause denial of service, though we consider the use of this vector unlikely because any such attack would require a significant privilege level and be easily traceable. |
| "managed-keys" is a feature which allows a BIND resolver to automatically maintain the keys used by trust anchors which operators configure for use in DNSSEC validation. Due to an error in the managed-keys feature it is possible for a BIND server which uses managed-keys to exit due to an assertion failure if, during key rollover, a trust anchor's keys are replaced with keys which use an unsupported algorithm. Versions affected: BIND 9.9.0 -> 9.10.8-P1, 9.11.0 -> 9.11.5-P1, 9.12.0 -> 9.12.3-P1, and versions 9.9.3-S1 -> 9.11.5-S3 of BIND 9 Supported Preview Edition. Versions 9.13.0 -> 9.13.6 of the 9.13 development branch are also affected. Versions prior to BIND 9.9.0 have not been evaluated for vulnerability to CVE-2018-5745. |
| BUSMASTER file parser abnormal exit in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service |
| A weakness has been identified in Open5GS up to 2.7.7. The affected element is the function smf_nudm_sdm_handle_get of the file src/smf/nudm-handler.c of the component SMF. Executing a manipulation of the argument preemptCap can lead to reachable assertion. The attack may be launched remotely. Upgrading to version 2.8.0 is sufficient to fix this issue. This patch is called 4554405f29bffd7562abedbee63484825bd90cd5. You should upgrade the affected component. |
| C12.22 protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service |
| OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.12, a crafted HTJ2K-compressed EXR file causes an unconditional process abort in any application that calls exr_start_read() on untrusted input, resulting in denial of service. The crash is triggered by a QCD marker whose lower five bits are zero, which OpenEXR passes into the vendored OpenJPH library while constructing the codestream and evaluating its quantization delta parameters. OpenJPH uses an assertion rather than a recoverable error to validate those bits, so any invalid value calls abort() directly and cannot be intercepted by surrounding error handling, a problem compounded by OpenEXR wrapping only its internal HT header parser in error handling while leaving the later codestream read and construction calls unprotected. This issue has been resolved in version 3.4.13. |
| A reachable assertion vulnerability in the NUDM-UECM interface of Open5GS v2.7.6 allows attackers to cause a Denial of Service (DoS) via supplying a crafted DELETE request. |
| A reachable assertion vulnerability in the /nsmf-pdusession/v1/sm-contexts component of Open5GS v2.7.6 allows attackers to cause a Denial of Service (DoS) via supplying a crafted DELETE request. |
| A reachable assertion was addressed with improved input validation. This issue is fixed in iOS 18.7.10 and iPadOS 18.7.10, iOS 26.5 and iPadOS 26.5, macOS Tahoe 26.5, visionOS 26.5, watchOS 26.5. An attacker in a privileged network position may be able to cause a denial-of-service. |
| OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.12, a reachable assertion failure in the HTJ2K decode path allows a crafted HTJ2K-compressed EXR file to cause an unconditional process abort in any application that calls exr_start_read() on untrusted input, resulting in denial of service. The crash is triggered by a QCD marker whose lower five bits are zero, which OpenEXR passes into the vendored OpenJPH library while constructing the codestream and evaluating its quantization delta parameters. OpenJPH uses an assertion rather than a recoverable error to validate those bits, so any invalid value calls abort() directly and cannot be intercepted by surrounding error handling, a problem compounded by OpenEXR wrapping only its internal HT header parser in error handling while leaving the later codestream read and construction calls unprotected. This issue has been resolved in version 3.4.13. |
| In the Linux kernel, the following vulnerability has been resolved:
ovl: don't warn when the mount is completed from another user namespace
fsopen() records the caller's user namespace in fc->user_ns and hands
back an ordinary file descriptor. Nothing ties the task that calls
fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The
fd is inherited across fork() and exec() and it can be passed over a
unix socket.
Completing a context from another user namespace is allowed on purpose.
vfs_cmd_create() authorizes the create with mount_capable(), which for
FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that
succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns.
So an unprivileged task can reach the WARN_ON() in ovl_fill_super():
create a user and a mount namespace in a child, call fsopen("overlay")
there, send the fscontext fd to the parent and let the parent issue
FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no
capability is needed anywhere:
WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]
CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn
Call Trace:
get_tree_nodev+0x71/0xa0
ovl_get_tree+0x15/0x20 [overlay]
vfs_get_tree+0x2a/0x100
vfs_cmd_create+0x60/0xf0
__do_sys_fsconfig+0x4b2/0x500
The child needs the mount namespace because fsopen() itself gates on
may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning
the caller's mount namespace. fsconfig() doesn't repeat that check.
It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be
raised in a loop to taint the kernel and flood the log, and it panics a
kernel booted with panic_on_warn.
Keep refusing the mount and stop warning about it. ovl_parse_param()
already spells a user namespace check this way for Opt_override_creds. |
| In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: don't warn when the mount is completed from another user namespace
fsopen() records the caller's user namespace in fc->user_ns and hands
back an ordinary file descriptor. Nothing ties the task that calls
fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The
fd is inherited across fork() and exec() and it can be passed over a
unix socket.
Completing a context from another user namespace is allowed on purpose.
vfs_cmd_create() authorizes the create with mount_capable(), which for
FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that
succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns.
So an unprivileged task can reach the WARN_ON() in bm_fill_super():
create a user and a mount namespace in a child, call
fsopen("binfmt_misc") there, send the fscontext fd to the parent and let
the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain
unshare(1) and no capability is needed anywhere:
WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc]
CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn
Call Trace:
get_tree_keyed+0x7d/0xb0
bm_get_tree+0x34/0x90 [binfmt_misc]
vfs_get_tree+0x2a/0x100
vfs_cmd_create+0x60/0xf0
__do_sys_fsconfig+0x4b2/0x500
The child needs the mount namespace because fsopen() itself gates on
may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning
the caller's mount namespace. fsconfig() doesn't repeat that check.
It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be
raised in a loop to taint the kernel and flood the log, and it panics a
kernel booted with panic_on_warn.
Keep refusing the mount and stop warning about it. Nothing in
bm_fill_super() depends on the two namespaces matching, it derives
everything from sb->s_user_ns. |
| A flaw has been found in Open5GS up to 2.8.0. This affects an unknown function of the file src/hss/hss-cx-path.c of the component HSS. This manipulation of the argument User-Name causes reachable assertion. The attack is possible to be carried out remotely. The exploit has been published and may be used. Patch name: c9abe09421eb99bbf1cd7862a3d375e58a4eb9e4. It is recommended to apply a patch to fix this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix BQL reset on SQ re-activation
mlx5e_queue_start() deactivates and re-activates all channels but closes
only the queue being restarted. mlx5e_activate_txqsq() then
unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters
of channels that kept their in-flight TX WQEs. The next completion then
over-charges and trips the BUG_ON() in dql_completed():
kernel BUG at lib/dynamic_queue_limits.c:99!
RIP: 0010:dql_completed+0x23d/0x280
Call Trace:
<IRQ>
mlx5e_poll_tx_cq+0x668/0xa60
mlx5e_napi_poll+0x5b/0x7b0
net_rx_action+0x15a/0x580
Reset BQL only when the SQ has no bytes in flight (sq->cc == sq->pc).
In the case that reset is skipped, the outstanding WQEs will eventually
complete and rebalance the dql. The dql->limit is carried across the
reset. |
| Libevent is an event notification library. Prior to 2.1.13 and 2.2.2-alpha, libevent has a heap out-of-bounds write in bufferevent_sock.c when bufferevent_socket_set_conn_address_ copies a kernel-supplied AF_UNIX peer address into bufferevent_private.conn_address. Release builds compiled with NDEBUG disable the EVUTIL_ASSERT length guard, and the evhttp accept path can pass a 110-byte sockaddr from accept() into the 28-byte field. An unauthenticated local peer able to connect to an AF_UNIX listener can overwrite the adjacent dns_request pointer and heap data, causing memory corruption with confidentiality, integrity, and availability impact. This issue is fixed in versions 2.1.13 and 2.2.2-alpha. |
| libheif is a HEIF and AVIF file format decoder and encoder. In 1.23.0 and earlier, a crafted HEIF or AVIF file containing a clean aperture box can reduce an image dimension to zero and crash or corrupt tiling results when heif_image_handle_get_image_tiling(handle, 1, &tiling) is called. ImageItem::get_heif_image_tiling() returns already transformed dimensions, and process_image_transformations_on_tiling() applies the clean aperture transformation again. The second application passes zero to Box_clap::left_rounded(0), where image_width minus one underflows and constructs Fraction(0xFFFFFFFF, 2). Debug builds reach an assertion and abort, while release builds can return a corrupt crop and zero-width tiling result. The affected implementation spans libheif/image-items/image_item.cc, libheif/context.cc, and libheif/box.cc. This issue is fixed in version 1.23.1. |
| libheif is a HEIF and AVIF file format decoder and encoder. In 1.23.0 and earlier, a crafted HEIF sequence accepted by heif_context_read_from_memory() can leave the context with no registered sequence tracks and crash when heif_context_get_track(ctx, 0) is called. HeifContext::get_track() in libheif/context.cc executes assert(has_sequence()) before its normal error handling, so assert-enabled builds abort instead of allowing the public wrapper in libheif/api/libheif/heif_sequences.cc to return null. In release builds, removing the assertion lets the track_id zero path dereference m_tracks.begin()->second on an empty map, which is undefined behavior and typically crashes. The issue is reachable through documented public APIs after parsing attacker-controlled bytes. This issue is fixed in version 1.23.1. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx8: drop unecessary BUG_ON()
There's no need to crash the kernel for this case.
(cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891) |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix 802.1X-SHA256 call trace warning
Based on wpa_auth as 1x_256 mode, need to set up
"use_fwsup" with BRCMF_PROFILE_FWSUP_1X.
Or it will happen trace warning when call brcmf_cfg80211_set_pmk().
[ 4481.831101] ------------[ cut here ]------------
[ 4481.831102] WARNING: CPU: 1 PID: 2997 at
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac]
[...]
[ 4481.831202] Call Trace:
[ 4481.831204] <TASK>
[ 4481.831205] nl80211_set_pmk+0x183/0x250 [cfg80211]
[ 4481.831233] genl_family_rcv_msg_doit+0xea/0x150
[ 4481.831237] genl_rcv_msg+0x104/0x240
[ 4481.831239] ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211]
[ 4481.831257] ? genl_family_rcv_msg_doit+0x150/0x150
[ 4481.831259] netlink_rcv_skb+0x4e/0x100
[ 4481.831261] genl_rcv+0x24/0x40
[ 4481.831262] netlink_unicast+0x236/0x380
[ 4481.831264] netlink_sendmsg+0x250/0x4b0
[ 4481.831266] sock_sendmsg+0x5c/0x70
[ 4481.831269] ____sys_sendmsg+0x236/0x2b0
[ 4481.831271] ? copy_msghdr_from_user+0x6d/0xa0
[ 4481.831272] ___sys_sendmsg+0x86/0xd0
[ 4481.831274] ? avc_has_perm+0x8c/0x1a0
[ 4481.831276] ? preempt_count_add+0x6a/0xa0
[ 4481.831279] ? sock_has_perm+0x82/0xa0
[ 4481.831280] __sys_sendmsg+0x57/0xa0
[ 4481.831282] do_syscall_64+0x38/0x90
[ 4481.831284] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 4481.831286] RIP: 0033:0x7fd270d369b4 |
| In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets
vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the
outer header, but for a Geneve-encapsulated packet the device can set
them based on the inner header instead, signalled by the
VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the
function never skips the outer encapsulation, this mismatch triggers:
- BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer
protocol is UDP (Geneve), not TCP.
- BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner
IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa).
Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the
function cannot locate the inner header it would need to parse. Also
convert the remaining BUG_ON()s in this function to return 0
defensively. |