Export limit exceeded: 395673 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 395673 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (395673 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-90205 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate orphan slot during inode read Patch series "ocfs2: validate active orphan slots during inode read". OCFS2 trusts active ordinary and append-DIO orphan slots read from dinodes. A corrupted slot can therefore index osb_orphan_wipes or the slot-local system-inode cache outside their allocations before the corruption is reported. Patch 1 validates the ordinary orphan slot used by inode wipe processing. Patch 2 validates the append-DIO orphan slot used by DIO completion and orphan recovery. Both checks reject corrupt metadata at the existing inode validation boundary. This patch (of 2): [BUG] A corrupted dinode with OCFS2_ORPHANED_FL can carry an i_orphaned_slot outside the mounted filesystem slot range. ocfs2_wipe_inode() uses it to index osb_orphan_wipes before looking up the orphan directory, causing an out-of-bounds memory access. BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_validate_inode_block() validates i_suballoc_slot but leaves the active ordinary orphan slot unchecked. Downstream consumers assume that the value is smaller than osb->max_slots. [FIX] Reject an active i_orphaned_slot outside the slot range during dinode validation, before the inode reaches orphan wipe processing. | ||||
| CVE-2026-90210 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in bpf_trampoline_multi_attach_free on update failure When bpf_trampoline_update() fails before modify_fentry_multi()/ unregister_fentry_multi() is called, cur_image is unchanged (cur_image == old_image) and ftrace still calls into it. Freeing old_image in that case causes a UAF. Only free old_image when it differs from cur_image. | ||||
| CVE-2026-69186 | 1 C-ares | 1 C-ares | 2026-09-20 | 5.3 Medium |
| c-ares is an asynchronous resolver library. Prior to 1.34.7, ares_dns_parse() trusts the attacker-controlled ANCOUNT, NSCOUNT, and ARCOUNT fields before confirming that the DNS response contains enough bytes for the claimed records. Because process_answer() invokes parsing before transaction ID and question validation, a malicious DNS response can cause ares_dns_record_rr_prealloc() and ares_array_set_size() to reserve disproportionate heap memory for a tiny message. Repeated responses create large allocation and release cycles that can degrade or deny name resolution, without causing memory corruption or information disclosure. This issue is fixed in version 1.34.7. | ||||
| CVE-2026-69184 | 1 C-ares | 1 C-ares | 2026-09-20 | 7.5 High |
| c-ares is an asynchronous resolver library. Prior to 1.34.7, ares_dns_name_parse() enforces backward DNS compression pointers but does not bound the total pointer hops or assembled name length. A malicious DNS server can send a response containing a long descending pointer chain and many resource records whose NAME or RDATA fields refer to the chain, causing repeated decompression work that grows quadratically with message size. A single crafted response can stall the single-threaded c-ares event loop and deny DNS resolution, without causing memory corruption or information disclosure. This issue is fixed in version 1.34.7. | ||||
| CVE-2026-81178 | 1 Syslifters | 1 Sysreptor | 2026-09-20 | 3.5 Low |
| SysReptor is a fully customizable pentest reporting platform. Prior to 2026.55, an unauthenticated holder of a public note share link receives project-wide collaborative editing metadata because the public share consumer joins the same collaboration group as authenticated project members and forwards client information, connection, awareness, and deletion events without consistently restricting them to the shared note subtree. The disclosed metadata can identify project members through usernames and names and reveal the identifiers and live editing activity of notes that were not shared. The content of non-shared notes remains protected, and the issue does not grant write access. This issue is fixed in version 2026.55. | ||||
| CVE-2026-90085 | 1 Linux | 1 Linux Kernel | 2026-09-20 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: fix NULL deref in NIX TM tree debugfs read path rvu_dbg_nix_tm_tree_display() dereferences pfvf->sq_ctx without checking whether the SQ context has been allocated. Reading /sys/kernel/debug/octeontx2/nix/tm_tree for a NIX LF whose transmit queues are not set up triggers a kernel oops. Guard the read path the same way rvu_dbg_nix_tm_tree_write() already does and return -EINVAL with a seq_file message when sq_ctx is NULL. | ||||
| CVE-2026-90086 | 1 Linux | 1 Linux Kernel | 2026-09-20 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: xsk: honor XDP_TX_METADATA in zero-copy path The zero-copy path reads TX metadata whenever the UMEM has metadata space, even if the descriptor does not set XDP_TX_METADATA. Pass descriptor options through the metadata helpers and ignore metadata unless the option is set. This does not fix the existing per-WQE metadata handling for mlx5 MPWQEs. Only the descriptor that starts a session passes through xsk_tx_metadata_request() and configures offload state shared by the batch. Metadata on descriptors joining an open session is therefore not validated and does not configure its requested offloads. In addition, a non-NULL metadata pointer from such a descriptor is treated as a timestamp completion request even when XDP_TXMD_FLAGS_TIMESTAMP is not set, so its metadata union can be overwritten with an unrequested timestamp. Fixing mixed metadata states within one MPWQE requires a separate change. | ||||
| CVE-2026-90088 | 1 Linux | 1 Linux Kernel | 2026-09-20 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc(). | ||||
| CVE-2026-90089 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Validate the FW dump header length nxp_process_fw_dump() pulls the ACL header off the frame and then reads seq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb->data, without checking that the ACL payload is long enough to contain it. h4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the number of payload bytes named in that header, so skb->len is 4 + dlen with dlen supplied by the controller and possibly smaller than the 8 byte dump header, or zero. A short frame with connection handle 0xfff therefore reads both fields from beyond the received data. Beyond the read itself, buf_len is what terminates a dump: a value of zero makes the driver call hci_devcd_complete() and reset the controller, so a truncated frame can end a dump early. Use skb_pull_data() to validate and pull the FW dump header before accessing its fields. Warn and reject the chunk if the header is truncated. | ||||
| CVE-2026-90090 | 1 Linux | 1 Linux Kernel | 2026-09-20 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX" ensures. | ||||
| CVE-2026-90099 | 1 Linux | 1 Linux Kernel | 2026-09-20 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: account classifier filter allocations to memcg Allocations in the tc classifier *_change() paths (filter objects, per-CPU counters, and per-filter aux data) use plain GFP_KERNEL without __GFP_ACCOUNT, allowing unprivileged users to pin kernel memory outside memcg charging. The shared tcf_exts_init_ex() action array allocation in cls_api.c was also uncharged; this patch closes it along with the per-classifier filter-object/percpu/aux allocations that remain unaccounted. Add GFP_KERNEL_ACCOUNT to: - the shared tcf_exts_init_ex() action array (cls_api.c), common to every filter of every classifier (32 pointers, 256 bytes); - the filter-object, per-CPU-counter, and per-filter aux allocations in cls_basic, cls_bpf, cls_cgroup, cls_flow, cls_flower, cls_fw, cls_matchall, cls_route and cls_u32; - the u32_init_knode() replace-path knode allocation (cls_u32.c), which allocates the same struct tc_u_knode + sel.keys on every replace of an existing knode and was missed by the create-path-only conversion. Also fix the cls_basic error path: basic_change() inserts fnew into the IDR before allocating the per-CPU counter. If alloc_percpu() fails the errout path kfree'd fnew without idr_remove, leaving a dangling pointer in the IDR. With GFP_KERNEL_ACCOUNT the percpu alloc becomes failable on demand (memcg at memory.max), making the dead path attacker-reachable and burning the handle permanently. Add the idr_remove on the percpu failure path, matching the basic_set_parms failure-path pattern. Note: vega@nebusec.ai provided a poc for basic_cls, but it was easy to extend to the other classifiers. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_CLS_* (the classifier being used), CONFIG_NET_CLS_ACT, CONFIG_MEMCG, CONFIG_USER_NS, CONFIG_NET_NS. - Unprivileged user in a fresh user+network namespace (unshare -Urn), or root with CAP_NET_ADMIN. - Create a large number of tc filters (e.g. tc filter add dev lo ingress ... <classifier> ...) while watching a memcg-limited cgroup: system slab grows far faster than memory.current, pinning kernel memory outside memcg charging. | ||||
| CVE-2026-90234 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: NFS: Return a delegation the client fails to record When an NFS server grants a delegation in an OPEN reply, nfs_inode_set_delegation() records it on the client. However, three of its error flows return without sending DELEGRETURN. A delegation can be relinquished only by DELEGRETURN (RFC 8881 Section 20.2.4), so dropping one silently leaves the server believing the client still holds it. If the server happens to recall that delegation, the client answers CB_RECALL with NFS4ERR_BADHANDLE because it has no record of the stateid. The server revokes the delegation and moves it onto its cl_revoked list, because the client never sends the FREE_STATEID that would drain it. Every subsequent SEQUENCE reply then carries SEQ4_STATUS_RECALLABLE_STATE_REVOKED, and the client's state manager loops issuing TEST_STATEID across its delegations without ever clearing the condition. The window is easy to reach now that a server offers a write delegation on any write OPEN: a delegation recalled for one opener races a re-open that the server answers with a fresh write delegation. Instead of dropping it, hand the delegation back during these error flows. | ||||
| CVE-2026-90312 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Check load-acquire src ptr type before the load check_atomic_load() calls check_load_mem() before atomic_ptr_type_ok(). For a load-acquire that fetches into its own source register (dst_reg == src_reg), check_load_mem() overwrites src_reg's type with the type of the loaded value, so the subsequent atomic_ptr_type_ok() no longer sees the source pointer and fails to reject the disallowed types (ctx, pkt, flow_keys, sock). Since bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw access to the underlying kernel object is left in place. The destination type is taken from the ctx access itself, so a load-acquire of the sk field of struct __sk_buff for example leaves the register typed as PTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match either, while it actually holds unconverted struct sk_buff bytes. Once the NULL check has passed this is a type confusion, not just a leak of kernel data. Validate src_reg with check_reg_arg() and check the source pointer type with atomic_ptr_type_ok() before the load again, mirroring check_atomic_rmw(). Out-of-range register numbers are already rejected earlier by check_and_resolve_insns() (commit 503d21ef8eac ("bpf: Do register range validation early")), and the only exemption there, is_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never matches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not dereference register state out of bounds, that is, the out-of-bounds read addressed by the Fixes commit below does not reappear (as proven also via selftest). | ||||
| CVE-2026-90321 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline xattrs during inode block validation Patch series "ocfs2: validate xattr entry bounds", v7. This series validates OCFS2 xattr entry name/value bounds when xattr metadata is read and validated, before getxattr() or listxattr() can walk out-of-range entry arrays or offsets from corrupted metadata. This patch (of 2): ocfs2_validate_inode_block() verifies a dinode before OCFS2 users walk metadata from it, but inline xattr metadata is still checked only in operation-specific consumers. The existing ibody lookup helper validates inline header placement and entry count, but inode block validation does not reject entry name/value bounds. Add a flat xattr entry validator and call it from inode block validation for inline xattrs. Keep the operation paths on their existing header/count lookup checks; the full entry bounds check now runs when the inode block is validated at read time. Reject corrupted inline xattr metadata before ocfs2_xattr_ibody_get() or listxattr() can walk past the inline storage. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_find_entry+0x5a/0x170 Read of size 2 at addr ffff8881242a2000 by task python3/529 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_find_entry+0x5a/0x170 ocfs2_xattr_get_nolock+0x20a/0x820 ocfs2_xattr_get+0x10c/0x1e0 __vfs_getxattr+0xe2/0x130 vfs_getxattr+0x185/0x1b0 | ||||
| CVE-2026-90326 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix race between policy activation and blkg destruction When switching an IO scheduler on a block device, blkcg_activate_policy() allocates blkg_policy_data (pd) for all blkgs attached to the queue. However, blkcg_activate_policy() may race with concurrent blkcg deletion, leading to use-after-free and memory leak issues. The use-after-free occurs in the following race: T1 (blkcg_activate_policy): - Successfully allocates pd for blkg1 (loop0->queue, blkcgA) - Fails to allocate pd for blkg2 (loop0->queue, blkcgB) - Enters the enomem rollback path to release blkg1 resources T2 (blkcg deletion): - blkcgA is deleted concurrently - blkg1 is freed via blkg_free_workfn() - blkg1->pd is freed T1 (continued): - Rollback path accesses blkg1->pd->online after pd is freed - Triggers use-after-free In addition, blkg_free_workfn() frees pd before removing the blkg from q->blkg_list. This allows blkcg_activate_policy() to allocate a new pd for a blkg that is being destroyed, leaving the newly allocated pd unreachable when the blkg is finally freed. Fix these races by extending blkcg_mutex coverage to serialize blkcg_activate_policy() rollback and blkg destruction, ensuring pd lifecycle is synchronized with blkg list visibility. | ||||
| CVE-2026-93116 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: asus-wmi: fix resource leaks on probe failure During driver initialization in asus_wmi_add(), various subsystems are registered sequentially. However, the error path labels are out of order relative to the registration sequence. Specifically: 1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to fail_custom_fan_curve. Because this label is placed below fail_sysfs, it bypasses the cleanup calls for the input device and sysfs groups, which were successfully registered before, leaking those resources. 2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad. Because fail_screenpad is placed below fail_backlight, it bypasses the cleanup calls for backlight and rfkill, leaking those resources. Fix these resource leaks by reordering the error path labels in asus_wmi_add() to match the exact reverse order of the resource allocations. | ||||
| CVE-2026-93165 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.7 High |
| In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length. | ||||
| CVE-2026-93189 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path ("hwmon: prevent packets from going to driver for probe", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit. | ||||
| CVE-2026-81180 | 1 Syslifters | 1 Sysreptor | 2026-09-20 | 8.8 High |
| SysReptor is a fully customizable pentest reporting platform. Prior to 2026.61, authenticated users of SysReptor Professional can upload image files whose formats cause image processing to invoke Ghostscript, allowing embedded PostScript to operate in the shared temporary directory. An attacker can combine that behavior with a race involving GnuPG configuration files in temporary subdirectories to cause GnuPG to copy attacker-controlled Python code into the application code directory. The injected code executes with the privileges of the SysReptor application process after a worker restart. The Community edition is not affected. Version 2026.58 contains a partial mitigation, and this issue is fully fixed in version 2026.61. | ||||
| CVE-2026-81182 | 1 Syslifters | 1 Sysreptor | 2026-09-20 | 4.2 Medium |
| SysReptor is a fully customizable pentest reporting platform. Prior to 2026.68, an unauthenticated attacker who holds a public read-write note share link can disclose an uploaded file or image from the same project by updating the shared note to reference the target asset filename. The user-controlled reference causes the shared-note authorization logic to treat the asset as permitted, after which the attacker can download it. The attacker must know the asset filename, and the issue does not permit cross-project access. This issue is fixed in version 2026.68. | ||||