Red Hat Linux Security Advisories & CVEs
5849 advisories tracked · Red Hat Security Data API · direct feeds checked every minute; rate-limited backstops use a safe source cadence
Android app · Google Play
Monitor Red Hat CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.
Security advisories for your Red Hat release
Pick your distribution release to see every advisory issued for it and its severity mix. Fixes ship as errata — keep the system patched. This is the release's advisory history, not a per-package scan.
Official source
Red Hat Security Data API
Red Hat Enterprise Linux errata (RHSA) via the official Red Hat Security Data API — CVE severity, CVSS and affected packages. A credential-free official source.
Latest Red Hat advisories
Medium [CVE-2026-74577] initialize rtm_tos in mpls_getroute
In the Linux kernel, the following vulnerability has been resolved: net: mpls: initialize rtm_tos in mpls_getroute() mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE,...)). It sets every field of the header except rtm_tos: r = nlmsg_data(nlh); r->rtm_family = AF_MPLS; r->rtm_dst_len= 20; r->rtm_src_len= 0; r->rtm_table= RT_TABLE_MAIN; r->rtm_type= RTN_UNICAST; r->rtm_scope= RT_SCOPE_UNIVERSE; r->rtm_protocol = rt->rt_protocol; r->rtm_flags= 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0...
Medium [CVE-2026-74449] Fix divide-by-zero in calculate_mcache_setting on zero viewport
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix divide-by-zero in calculate_mcache_setting on zero viewport If a plane reaches calculate_mcache_setting with a zero-area viewport, calculate_mcache_setting exits early with num_mcaches == 0 and mvmpg_width/height == 0. This will cause a divide-by-zero panic and can also cause an underflow on num_mcaches. Fix this by changing calculate_mcache_setting to bool and adding guards after each calculate_mcache_row_bytes call. Callers will propagate the failure as a rejected mode, which prevents the panic. (cherry picked from commit 29c0f7c655f47bcbd575ff75e58480df6ec3c9da) A flaw was found in the display driver component of the Linux kernel. A local attacker could exploit a vulnerability related to how the system handles display settings, specifically when processing certain display configurations. This could lead to a system crash, resulting in a Denial of Service (DoS) for the affected system. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-369. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-74552] (lm90) Only report alarms if driver is ready
In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Only report alarms if driver is ready Userspace can read sysfs attributes before driver registration is complete, immediately after devm_hwmon_device_register_with_info() has been called. At that time, data->hwmon_dev is not yet initialized. This can trigger a NULL pointer access since lm90_update_device() and with it lm90_update_alarms_locked() will be called. This call schedules report_work and lm90_report_alarms(), which passes the still-NULL data->hwmon_dev to hwmon_notify_event() and triggers a NULL pointer dereference. Fix the problem by only scheduling the report and alert workers data->hwmon_dev is set. A local user can trigger a null pointer dereference by reading sysfs attributes before the driver's registration is complete. This can lead to a system crash, resulting in a denial of service. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-824. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-74457] add bounds check for USB channel index
In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: add bounds check for USB channel index The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error(). A malicious USB device could send a specially crafted payload, leading to a heap out-of-bounds read. This vulnerability can cause a kernel panic, resulting in a Denial of Service (DoS) for the affected system. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-125. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-74444] validate DRAW_PRIMITIVES header size before division
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate DRAW_PRIMITIVES header size before division vmw_cmd_draw() computes maxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front. A local attacker could exploit an issue in the `vmw_cmd_draw()` function by providing a specially crafted `DRAW_PRIMITIVES` header with an undersized value. This can lead to an out-of-bounds read of kernel memory, potentially allowing for information disclosure. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-125. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-74576] prevent unbounded recursion in free path with new kmalloc type
In the Linux kernel, the following vulnerability has been resolved: mm/slab: prevent unbounded recursion in free path with new kmalloc type Commit 280ea9c3154b ("mm/slab: avoid allocating slabobj_ext array from its own slab") avoided recursive allocation of obj_exts from kmalloc caches of the same size, by bumping the obj_exts array's allocation size whenever the array size equals the size of the object being allocated. However, as reported by Danielle Costantino and Shakeel Butt, even slabs from kmalloc caches of different sizes can form a cycle by allocating obj_exts arrays from each other [1]: What happened: a KMALLOC_NORMAL slab's obj_exts array (used by allocation profiling / memcg accounting) is itself kmalloc()'d from a KMALLOC_NORMAL cache, so the "slab holds another slab's obj_exts array" relation can form cycles. With sizeof(struct slabobj_ext) == 16 and the host's geometry: - kmalloc-512 has 64 objects/slab -> array is 64*16 == 1024 bytes, served from kmalloc-1k; - kmalloc-1k has 32 objects/slab -> array is 32*16 == 512 bytes, served from kmalloc-512. Discarding one frees the other's array, which empties and discards that slab, which frees the first's array, and so on: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() recurses along the cycle until the stack is exhausted.
Medium [CVE-2026-74524] Fix out-of-bounds page-table walk during memory hot-remove
In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove remove_pud_mapping() and remove_p4d_mapping() obtain a child table base with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for addr. RISC-V folds page-table levels at runtime. When a level is folded, its offset helper returns the parent entry itself, but the index can still be nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39 folds both P4D and PUD, so memory hot-remove can descend into unrelated memory and pass an invalid page to __free_pages(). This can trigger: kernel BUG at include/linux/mm.h:1810! VM_BUG_ON_PAGE(page_ref_count(page) == 0) arch_remove_memory+0x1e/0x5c try_remove_memory+0x15e/0x200 remove_memory+0x24/0x3c Only add the index when the corresponding page-table level is enabled, matching p4d_offset() and pud_offset(). When performing memory hot-remove operations on systems using RISC-V architecture, an out-of-bounds page-table walk can occur. This issue arises because the system attempts to access memory outside of its designated boundaries, potentially leading to a kernel bug and a system crash. This vulnerability could allow a local attacker to cause a denial of service. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-787.
Medium [CVE-2026-74523] sync udp_tunnel ports outside qede_lock in the recovery path
In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case.
Medium [CVE-2026-74463] Cache host clock rate at probe to prevent CCF prepare_lock deadlock
In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe().
Medium [CVE-2026-74466] Close speculative mem read possibility
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Close speculative mem read possibility The domain value is extracted from a given CCA or EP11 ioctl struct when a CPRB is about to be sent. Thus this is a user controlled value. Under some special conditions (custom device node used, administrative load) this value is used as an array index after bounds checking, but without speculation barrier. Add the missing array_index_nospec() call to prevent speculative execution where this domain value is used. This oversight could allow for speculative memory reads, potentially leading to information disclosure. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-125. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-74540] fix UAF in l2cap_le_connect_rsp
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers. A flaw was found in the Linux kernel's Bluetooth L2CAP (Logical Link Control and Adaptation Protocol) component. A use-after-free (UAF) vulnerability exists in the `l2cap_le_connect_rsp()` function, where a channel can be freed while still being referenced. This can be triggered by a remote disconnect, potentially allowing a remote attacker to corrupt memory and achieve arbitrary code execution or cause a denial of service. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-825.
Medium [CVE-2026-74250] Autodetect deploy interface fails to run cleaning
In OpenStack Ironic before 38.0.1, the autodetect deploy interface may fail to run cleaning immediately after enrollment with, or changing to, the autodetect deploy interface. This can lead to operational issues where necessary cleaning procedures are not executed. This could allow data from a previous tenant to remain on the hardware, potentially exposing sensitive information to subsequent tenants. This vulnerability was introduced in ironic version 32.0.0 and is fixed in versions 35.0.2 and 38.0.1. Red Hat severity: Moderate. Weakness: CWE-367. Affected Red Hat products: Red Hat OpenShift Container Platform 4. Red Hat lists Red Hat OpenStack Platform 16.2 as not affected. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-74247] SSRF via build archive_url in Quay build API
A flaw was found in Red Hat Quay. A user with FEATURE_BUILD_SUPPORT enabled and repository write access can exploit a Server-Side Request Forgery (SSRF) vulnerability within the build API. This allows the user to provide a malicious URL, causing the Quay builder to make requests to internal network addresses. Such an action could lead to the disclosure of sensitive internal information. Exploitation requires specific configuration and privileges, limiting the attack surface. Successful exploitation could enable access to internal network resources from the Quay builder. Red Hat severity: Moderate — CVSS 4.2 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N). Weakness: CWE-918. Affected Red Hat products: Red Hat OpenShift Update Service; Red Hat Quay 3. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-74245] Unauthenticated exported logs download in Quay
A flaw was found in Red Hat Quay's exported logs feature. An unauthenticated attacker with a valid file ID could download exported action logs without proper authorization. While file IDs are complex, they can be intercepted from plaintext email or webhook callbacks. This vulnerability leads to information disclosure, potentially exposing sensitive data such as usernames, email addresses, IP addresses, and action-specific metadata. Deployments using LocalStorage backends are at higher risk due to indefinite log file persistence. Red Hat severity: Moderate — CVSS 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N). Weakness: CWE-306. Affected Red Hat products: Red Hat OpenShift Update Service; Red Hat Quay 3. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-74244] Stripe webhook accepts forged events without signature verification in Quay
A flaw was found in Red Hat Quay's Stripe billing webhook handler. This vulnerability allows an unauthenticated attacker to forge billing events by sending crafted JSON requests to the `/webhooks/stripe` endpoint without validating the Stripe-Signature header. Successful exploitation can lead to the unauthorized resetting of a namespace's build quota to its maximum and trigger unsolicited billing emails to namespace administrators. The vulnerability is present even when the billing feature is disabled, though its impact is reduced in self-hosted deployments utilizing FakeStripe. Red Hat severity: Moderate — CVSS 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N). Weakness: CWE-347. Affected Red Hat products: Red Hat OpenShift Update Service; Red Hat Quay 3. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-74243] Unauthenticated secscan notification endpoint in Quay when PSK is unset
A flaw was found in Red Hat Quay. When the SECURITY_SCANNER_V4_PSK (pre-shared key) is not set, a remote unauthenticated attacker can send POST requests to the security scanner notification endpoint. This allows the attacker to flood the notification queue and inject path traversal characters into Clair API URL paths. The primary consequence is worker resource exhaustion and blind path manipulation on the configured Clair host, potentially leading to a denial of service. This risk is primarily present in standalone Quay installations where the `SECURITY_SCANNER_V4_PSK` is not explicitly configured, as operator-managed deployments automatically generate this key. Red Hat severity: Moderate — CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L). Weakness: CWE-306. Affected Red Hat products: Red Hat OpenShift Update Service; Red Hat Quay 3. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-74242] Repository notification UUID IDOR in Quay API
A flaw was found in Red Hat Quay. An administrator of any repository, by knowing or guessing a target notification's Universally Unique Identifier (UUID), can read the notification configuration, including sensitive details like webhook URLs, Slack tokens, and email addresses. This vulnerability also allows them to trigger test notifications for another repository. This could lead to unauthorized information disclosure and potential misuse of notification services. Exploitation requires knowledge of a specific 128-bit notification UUID, which limits the likelihood of successful attacks despite the potential for information disclosure. Red Hat severity: Moderate — CVSS 5.3 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N). Weakness: CWE-639. Affected Red Hat products: Red Hat OpenShift Update Service; Red Hat Quay 3. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-74241] LDAP referral filter injection in Quay external LDAP authentication
A flaw was found in Red Hat Quay's external Lightweight Directory Access Protocol (LDAP) authentication handling. When an LDAP referral is returned during authentication, the system does not properly escape the username input. This allows an attacker to inject LDAP filter metacharacters, enabling user-existence oracle attacks at the referral Directory Name (DN). This could also potentially influence which DN is used for password binding in multi-domain Active Directory environments. This Moderate impact flaw in Red Hat Quay's external LDAP authentication arises from improper sanitization of username input during LDAP referral processing. While direct authentication bypass is prevented and directory enumeration is limited, an attacker could exploit this to conduct user-existence oracle attacks against referral DNs, potentially influencing password binds in multi-domain Active Directory setups. Red Hat severity: Moderate — CVSS 4.8 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N). Weakness: CWE-90. Affected Red Hat products: Red Hat OpenShift Update Service; Red Hat Quay 3. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-74240] JWT claim validation bypasses in Quay federated robot and SSO authentication
A flaw was found in Red Hat Quay's JWT (JSON Web Token) validation for federated robot accounts and single sign-on (SSO) authentication. Multiple issues related to audience verification and the enforcement of `azp` and `sub` claims were identified. These flaws could allow an attacker with a validly-signed token from the same identity provider to bypass configured security restrictions. This bypass could lead to unauthorized access by circumventing intended audience, subject, or authorized-client limitations. This is due to default configurations for federated robot authentication not enforcing audience verification, and insufficient checks for 'azp' and 'sub' claims in certain scenarios. Exploitation requires a pre-existing valid token from the same IdP, limiting the attack surface. Red Hat severity: Moderate — CVSS 5.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N). Weakness: CWE-287. Affected Red Hat products: Red Hat OpenShift Update Service; Red Hat Quay 3. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-49263] Denial of Service and parser desynchronization via WebAssembly `br_table` instruction-size truncation
Capstone is a disassembly framework. Prior to version 6.0.0-Alpha9, Capstone's WebAssembly backend accepts attacker-controlled raw WASM instruction bytes through the public `cs_disasm()` and `cs_disasm_iter()` APIs. For a large but well-formed `br_table` instruction, the WASM decoder accumulates the immediate length in a wider local variable but returns it through a `uint16_t` instruction-size path. When the encoded instruction length is exactly 65,536 bytes, the size wraps to zero and `cs_disasm()` can repeatedly decode the same instruction without advancing. For larger lengths, `cs_disasm_iter()` advances into the middle of the `br_table` payload and decodes target bytes as subsequent instructions. This is an availability and parser-integrity issue. A remote attacker could exploit this by providing a specially crafted `br_table` instruction. This could lead to a denial of service, where the disassembler gets stuck in a loop, or cause parser desynchronization, leading to incorrect disassembly of subsequent instructions. Red Hat severity: Moderate — CVSS 6.8 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H). Weakness: CWE-190. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat Hardened Images; Red Hat OpenShift Container Platform 4. Red Hat does not currently list a fixing RHSA for this CVE.