Export limit exceeded: 85973 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (85973 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-19917 | 1 Code-projects | 1 Online Food Order System | 2026-08-15 | 6.3 Medium |
| A flaw has been found in code-projects Online Food Order System 1.0. The impacted element is an unknown function of the file delete_food_items1.php. Executing a manipulation of the argument checkbox can lead to sql injection. The attack can be executed remotely. The exploit has been published and may be used. | ||||
| CVE-2026-19916 | 1 Code-projects | 1 Online Food Order System | 2026-08-15 | 3.5 Low |
| A vulnerability was detected in code-projects Online Food Order System 1.0. The affected element is an unknown function of the file edit_food_items.php. Performing a manipulation of the argument dname results in cross site scripting. Remote exploitation of the attack is possible. The exploit is now public and may be used. | ||||
| CVE-2026-73053 | 1 B3log | 1 Siyuan | 2026-08-15 | 9 Critical |
| SiYuan versions before v3.7.4 contain a cross-site scripting vulnerability in the unicode2Emoji function that fails to sanitize codepoint branch output. Attackers can craft document icons with hex-encoded markup that executes in the renderer with Node integration enabled, achieving arbitrary code execution on the host system. | ||||
| CVE-2026-73052 | 1 B3log | 1 Siyuan | 2026-08-15 | 9 Critical |
| SiYuan before v3.7.4 stores attribute-view field names without HTML escaping and interpolates them directly into option elements via innerHTML in the sort menu. Attackers can inject markup by renaming a database field to execute arbitrary JavaScript when users open the sort menu, with Node integration enabled in the desktop client enabling code execution. | ||||
| CVE-2026-73050 | 1 B3log | 1 Siyuan | 2026-08-15 | 9 Critical |
| SiYuan versions before v3.7.4 fail to validate or escape the color field in attribute-view select options, allowing stored cross-site scripting through eight unescaped render sites. Attackers can inject event-handler attributes by including quotation marks in the color value, executing arbitrary JavaScript when viewing databases containing the malicious select field. | ||||
| CVE-2026-73044 | 1 B3log | 1 Siyuan | 2026-08-15 | 9 Critical |
| SiYuan versions before v3.7.4 fail to validate or escape table column width values, allowing stored cross-site scripting injection into style attributes. Attackers can inject malicious payloads through the setAttrViewColWidth API that break out of style attributes and inject event handlers on every table cell, executing arbitrary code in the Electron renderer with Node integration enabled. | ||||
| CVE-2026-73043 | 1 B3log | 1 Siyuan | 2026-08-15 | 9 Critical |
| SiYuan versions before v3.7.4 contain a remote code execution vulnerability in the Template calculation operator, which renders user-authored Go templates and stores output verbatim without sanitization. Attackers can inject malicious HTML and JavaScript into template calculations that execute in the desktop client renderer with Node integration enabled, allowing arbitrary code execution when the database is opened. | ||||
| CVE-2026-73042 | 1 B3log | 1 Siyuan | 2026-08-15 | 9 Critical |
| SiYuan before v3.7.4 fails to properly escape database menu metadata in HTML interpolation, allowing stored values to execute script when users open group, view, or field-edit menus. Attackers can inject markup through field descriptions or names that close containing elements and execute arbitrary code via event handlers, reaching Node built-ins due to Electron's insecure configuration. | ||||
| CVE-2026-73041 | 1 B3log | 1 Siyuan | 2026-08-15 | 9 Critical |
| SiYuan versions before v3.7.4 fail to validate or escape annotation fields written to disk by the setFileAnnotation endpoint. Attackers can inject malicious markup into annotation fields that execute as script in the PDF renderer with full Node.js access when a user opens an annotated PDF. | ||||
| CVE-2026-68462 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative const offsets for buffer pointers The verifier rejects variable offsets for PTR_TO_TP_BUFFER and PTR_TO_BUF accesses, but it currently accepts a constant negative offset produced by pointer arithmetic. Commit 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers") moved constant pointer offsets from reg->off to reg->var_off. However, __check_buffer_access() continued to check only the instruction offset. An access with reg->var_off equal to -8 and an instruction offset of zero therefore passes verification. For writable raw tracepoints, the access end is also calculated from the unsigned reg->var_off.value. An eight-byte access starting at -8 wraps the calculated end to zero, allowing the program to load and attach without increasing max_tp_access. After ensuring that reg->var_off is constant, calculate the effective access start using signed arithmetic and reject it when it is negative. Use the validated start to calculate the access end for both PTR_TO_TP_BUFFER and PTR_TO_BUF. | ||||
| CVE-2026-68475 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: reset: sunxi: fix memory region leak on ioremap failure In sunxi_reset_init(), when ioremap() fails, the memory region obtained via request_mem_region() is not released, leading to a resource leak. Add an err_mem_region label to properly release the memory region before freeing the data structure. | ||||
| CVE-2026-68476 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head. | ||||
| CVE-2026-72028 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: riscv: probes: save original sp in rethook trampoline Reading a word from the stack in a kretprobe crashes a risc-v kernel. $ cd /sys/kernel/tracing/ $ echo 'r n_tty_write $stack0' > dynamic_events $ echo 1 > events/kprobes/enable Unable to handle kernel paging request at virtual address 0000000200000128 ... [<ffffffff80016d16>] regs_get_kernel_stack_nth+0x26/0x38 [<ffffffff80177196>] process_fetch_insn+0x3ee/0x760 [<ffffffff80177836>] kretprobe_trace_func+0x116/0x1f0 [<ffffffff8017795a>] kretprobe_dispatcher+0x4a/0x58 [<ffffffff8013572e>] kretprobe_rethook_handler+0x5e/0x90 [<ffffffff80180838>] rethook_trampoline_handler+0x70/0x108 [<ffffffff8001ba32>] arch_rethook_trampoline_callback+0x12/0x1c [<ffffffff8001ba84>] arch_rethook_trampoline+0x48/0x94 [<ffffffff8067872a>] tty_write+0x1a/0x30 In regs_get_kernel_stack_nth, regs->sp contains an arbitrary value. arch_rethook_trampoline saves the registers from the probed function in a struct pt_regs. sp is not saved. Instead, sp is decremented for arch_rethook_trampoline's local stack. Fix this crash and save the original sp along with the other registers. Use a0 as a temporary register, it is overwritten anyway. [pjw@kernel.org: added Fixes tag; cc'ed stable] | ||||
| CVE-2026-72042 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ipmi: Fix user refcount underflow in event delivery ipmi_alloc_recv_msg(user) takes the temporary user reference owned by the receive message, and ipmi_free_recv_msg() drops it again. If event delivery fails after allocating receive messages for earlier users, handle_read_event_rsp() rolls those messages back with ipmi_free_recv_msg(). That rollback path still drops user->refcount explicitly after freeing each message. The extra put can free a user that remains linked on intf->users, so later event delivery may dereference a freed user or trip refcount_t's addition-on-zero warning when ipmi_alloc_recv_msg() tries to acquire another reference. Remove the stale explicit put and the now-dead user assignment. Keep the list_del() and ipmi_free_recv_msg() calls; they are the required rollback operations. | ||||
| CVE-2026-72058 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: ixp4xx_hss: fix duplicate HDLC netdev allocation ixp4xx_hss_probe() allocates two HDLC netdevs. The first one is stored in ndev, initialized, and registered with register_hdlc_device(). The second one is stored in port->netdev and later used by the remove path for unregister_hdlc_device() and free_netdev(). This means that the registered netdev is not the same object that is unregistered and freed on remove. It also leaks the first allocation if the second alloc_hdlcdev() call fails, and the first allocation is not checked before ndev is used. Older code allocated the HDLC netdev only once and stored the same object in both the local variable and port->netdev. The buggy conversion split this into two alloc_hdlcdev() calls. A later rename changed the local variable name to ndev, but the underlying mismatch remained. Fix this by allocating the HDLC netdev only once and assigning the same object to port->netdev. | ||||
| CVE-2026-72178 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: always put unsuccessfully committed target pids damon_commit_target() puts and gets the destination and the source target pids. It puts the destination target pid because it will be overwritten by the source target pid. It gets the source pid because the caller is supposed to eventually put the pids. In more detail, the caller will call damon_destroy_ctx() after damon_commit_ctx() to destroy the entire source context. And in this case, [f]vaddr operation set's cleanup_target() callback will put the pids. The commit operation is made at the context level. The operation can fail in multiple places including in the middle and after the targets commit operations. For any such failures, immediately the error is returned to the damon_commit_ctx() caller. If some or all of the source target pids were committed to the destination during the unsuccessful context commit attempt, those pids should be put twice. The source context will do the put operations using the above explained routine. However, let's suppose the destination context was not originally using [f]vaddr operation set and the commit failed before the ops of the source context is committed. The destination does not have the cleanup_target() ops callback, so it cannot put the pids via the damon_destroy_ctx(). As a result, the pids are leaked. The issue in the real world would be not very common. The commit feature is for changing parameters of running DAMON context while inheriting internal status like the monitoring results. The monitoring results of a physical address range ain't have things that are beneficial to be inherited to a virtual address ranges monitoring. So the problem-causing DAMON control would be not very common in the real world. That said, it is a supported feature. And damon_commit_target() failure due to memory allocation is relatively realistic [1] if there are a huge number of target regions. Fix by putting the pids in the commit operation in case of the failures. The issue was discovered [2] by Sashiko. | ||||
| CVE-2026-72240 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix reference leak on failed device registration When platform_device_register() fails in sm501_register_device(), the embedded struct device in pdev has already been initialized by device_initialize(), but the failure path only reports the error and returns without dropping the device reference for the current platform device: sm501_register_device() -> platform_device_register(pdev) -> device_initialize(&pdev->dev) -> setup_pdev_dma_masks(pdev) -> platform_device_add(pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review. | ||||
| CVE-2026-72144 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-laptop: fix missing cleanups in init error path dell_init() initializes several resources after dell_setup_rfkill(), including the optional touchpad LED, keyboard backlight LED, battery hook, debugfs directory and dell-laptop notifier. If a later LED or backlight registration fails, the error path only tears down the battery hook and rfkill resources. This leaves the notifier, debugfs directory, keyboard backlight LED and optional touchpad LED registered after dell_init() returns an error. Add the missing cleanup calls before tearing down rfkill. | ||||
| CVE-2026-72169 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES When using scratch_scale, the scratch sizes are rounded up to CMA_MIN_ALIGNMENT_BYTES since they will be released as MIGRATE_CMA. This is not done when using fixed scratch sizes via command line. This can result in user specifying a size which is not aligned, and thus kernel releasing a pageblock that is only partially scratch. Do the rounding up for both cases in scratch_size_update(). | ||||
| CVE-2026-72173 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: do not warn on seeing non-migration pmd entry Patch series "mm/hmm: A fix and a selftest", v3. Patch 1 fixes a stale warning present from the time when only migration softleaf entries were supported at the PMD level. Patch 2 adds some code into hmm-tests.c which exercises the pagemap path for PMD device-private entries. This patch (of 2): pagemap_pmd_range_thp() warns if a non-present PMD is not a migration entry. This became false once device-private entries at the PMD level were added. Therefore, remove the stale migration-only assertion. | ||||