Search Results (25046 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-6721 2 Ibm, Linux 2 Concert, Linux Kernel 2026-09-28 9.8 Critical
IBM Concert 1.0.0 through 3.0.0 allows an unauthenticated remote attacker can supply specially crafted input that is incorporated into OS commands, resulting in arbitrary command execution on the underlying system. Successful exploitation allows remote code execution with the privileges of the affected application.
CVE-2026-6327 2 Ibm, Linux 2 Concert, Linux Kernel 2026-09-28 4.3 Medium
IBM Concert 1.0.0 through 3.0.0 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files.
CVE-2026-6718 2 Ibm, Linux 2 Concert, Linux Kernel 2026-09-28 6.2 Medium
IBM Concert 1.0.0 through 3.0.0 is vulnerable to improper access control which allows unauthorized modification of application files.
CVE-2026-3626 2 Ibm, Linux 2 Concert, Linux Kernel 2026-09-28 5.3 Medium
IBM Concert 1.0.0 through 3.0.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system.
CVE-2026-93782 1 Linux 1 Linux Kernel 2026-09-28 7.8 High
In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: flush backend after device ioctls vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns.
CVE-2026-93785 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: cifs: validate idmap key payload length The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads.
CVE-2026-93786 1 Linux 1 Linux Kernel 2026-09-28 8.1 High
In the Linux kernel, the following vulnerability has been resolved: ksmbd: preserve VFS inherited POSIX ACL mask The VFS initializes a child's POSIX ACL from the parent's default ACL and the requested creation mode. Do not mutate the parent ACL or overwrite the child's VFS-computed access and default ACLs afterwards. This preserves restrictive ACL_MASK entries and prevents SMB object creation from widening effective permissions.
CVE-2026-93789 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: bound aligned TLV advance in FW parser Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs.
CVE-2026-98163 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: cgroup: Avoid iteration of dying tasks with zero refcount The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") extended the lifetime of tasks on the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration. The repeat: loop in css_task_iter_advance() doesn't consider ->usage count, so add a new loop to css_task_iter_next() to skip de-used tasks on the dying_list. Rough illustration of the possible race R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader && signal->live != 0 => it->task_pos = &L->cg_list release css_set_lock T exits --signal->live == 0 cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU... put_task_struct(L) L->usage = 0 /* L still on dying_tasks */ ...RCU... __put_task_struct(L) css_task_iter_next() // another iteration take css_set_lock it->task_pos = &L->cg_list get_task_struct(L) => addition on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // dying skip comes too late free_task(L) cgroup_procs_show() task_pid_vnr(L)
CVE-2026-97561 1 Linux 1 Linux Kernel 2026-09-28 7.0 High
In the Linux kernel, the following vulnerability has been resolved: smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid When the administrator mounts with forceuid or forcegid (uid=/gid= mount options), they expect all files to appear owned by the specified user/group. However, several code paths unconditionally called sid_to_id() to overwrite cf_uid/cf_gid with server-provided values, ignoring the administrator's explicit override: - smb311_posix_info_to_fattr() (stat via POSIX extensions) - cifs_posix_to_fattr() (readdir via POSIX extensions) - parse_sec_desc() (CIFS ACL ownership mapping) This allowed an untrusted server to dictate local file ownership even when the mount was configured to force specific uid/gid values. Fix all three call sites to check CIFS_MOUNT_OVERR_UID and CIFS_MOUNT_OVERR_GID before calling sid_to_id(), following the same pattern already used by cifs_unix_basic_to_fattr() for unix extensions.
CVE-2026-97554 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr() cifs_posix_to_fattr() ignores the return value of posix_info_parse(). When a malformed POSIX directory entry is encountered (e.g. invalid SID lengths from an untrusted server), posix_info_parse() returns -1 without populating the 'parsed' struct. The uninitialized stack memory in parsed.owner and parsed.group is then passed to sid_to_id(), which processes the garbage bytes and passes them to request_key() to construct a SID string, potentially leaking kernel stack contents to the userspace idmap daemon. Fix this by checking the return value and skipping the SID-to-id mapping when parsing fails. The remaining fattr fields (timestamps, mode, etc.) are populated directly from the 'info' pointer so they are unaffected.
CVE-2026-97541 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: don't store usb_device_id usb_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. All information apart from driver_data can be easily retrieved from usb_device, so just store driver_data.
CVE-2026-97540 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: don't rely on id table pointer arithmetic The current code is broken when dynamic ID is involved; in such cases usb_device_id parameter of probe lives on the heap and the pointer arithmetic will get an index that is wildly out of bound. Instead of keeping a side table for additional information, use driver_info field of the usb_device_id. The dynamic ID parsing code needs to be updated for this; convert it to just write to the reserved entry for dynamic ID and remove the weird loop.
CVE-2026-97539 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: usb: xusbatm: don't rely on id table pointer arithmetic The current code is broken when dynamic ID is involved; in such cases usb_device_id parameter of probe lives on the heap and the pointer arithmetic will get an index that is wildly out of bound. xusbatm initialize the USB device IDs dynamically so it can just use driver_info too. Even with conversion, xusbatm still cannot support dynamic IDs, so also set no_dynamic_id.
CVE-2026-97537 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking qla25xx_free_req_que() and qla25xx_free_rsp_que() have two pre-existing bugs exposed on the error path of qla25xx_create_{req,rsp}_que(): 1. When dma_alloc_coherent() fails during queue creation, the error path calls the free function with req->ring / rsp->ring still NULL (from kzalloc). The unconditional dma_free_coherent() with a NULL cpu_addr is undefined behavior and can panic. 2. The free functions clear req_qid_map / rsp_qid_map under vport_lock, but the create functions protect the same bitmaps with mq_lock. This provides no mutual exclusion. Additionally, the create error path clears the bit and releases mq_lock before calling the free function, creating a window where another thread can allocate the same que_id and have its ha->req_q_map entry clobbered by the subsequent lockless NULL assignment in the free function. Fix by: - Guarding dma_free_coherent() with a NULL check on the ring pointer. - Using mq_lock (the lock held by all creators) in the free functions to atomically NULL the map entry and clear the bitmap bit. - Removing the now-redundant clear_bit blocks from the create error paths since the free functions handle it atomically.
CVE-2026-97532 1 Linux 1 Linux Kernel 2026-09-28 7.0 High
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Null out freed pointers in qla2x00_mem_alloc() error path When qla2x00_mem_alloc() fails, qla2x00_probe_one() jumps to probe_hw_failed and calls qla2x00_mem_free(). Several error labels in qla2x00_mem_alloc() freed adapter members (elsrej.c, purex_dma_pool, flt, sfp_data, loop_id_map, async_pd, sf_init_cb, ex_init_cb, npiv_info) but left the pointers dangling. qla2x00_mem_free() then freed them a second time. Worse, for the dma_pool members it issued dma_pool_free(ha->s_dma_pool, ...) after s_dma_pool had already been destroyed and set to NULL at fail_s_dma_pool, dereferencing a NULL pool. Clear each freed pointer (and its DMA handle) in the error labels so the subsequent qla2x00_mem_free() skips them.
CVE-2026-97521 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: gfs2: fix quota init duplicate scan gfs2_quota_init() checks for duplicate quota_change IDs while holding qd_lock and the quota hash bucket bitlock. That path used gfs2_qd_search_bucket(), which takes a lockref reference via lockref_get_not_dead(). On PREEMPT_RT this may sleep, which is not allowed under the bucket bitlock, triggering "sleeping function called from invalid context". Use a no-ref bucket lookup in this path, then continue duplicate handling without taking a lockref there. Refactor gfs2_qd_search_bucket() to build on top of the no-ref helper so lookup traversal stays in one place. This patch fixes a bug reported by syzbot.
CVE-2026-97519 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix null pointer dereference in devcoredump cleanup In xe_devcoredump_snapshot_free(), ss->gt may be NULL when the snapshot was never fully populated (e.g., when cleanup is triggered without a prior capture). Guard the xe_guc_capture_put_matched_nodes() call with IS_ERR_OR_NULL() to prevent a null dereference. In xe_devcoredump_free(), the deferred work is only queued when a coredump is captured, so guard cancel_work_sync() with a check on coredump->captured.
CVE-2026-97518 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: reject duplicate wiphy cipher suite entries Duplicate entries in wiphy->cipher_suites do not describe any additional capability, but cfg80211 currently accepts them and leaves individual consumers to deal with them. One such consumer is the WEXT compatibility code, which appends a WEP key length for each WEP cipher entry it sees. Repeated WEP entries can therefore overflow the fixed iw_range::encoding_size array returned by SIOCGIWRANGE. Reject duplicate cipher suite entries in wiphy_register() instead. This keeps the cipher suite invariant in one place and makes malformed wiphy descriptions fail early with -EINVAL, rather than relying on a single cfg80211 user to handle duplicates correctly.
CVE-2026-97517 1 Linux 1 Linux Kernel 2026-09-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject beacons with bad HE operation The HE operation element not only needs to be longer than the fixed part, but also have an appropriate size for the variable part inside of it. Check this.