Vulnerabilities

Cross Site Request Forgery vulnerability in Bagisto before v.1.5.1 allows an attacker to execute arbitrary code via a crafted HTML script.

Rejected reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not in the allowed scope of that CNA's CVE ID assignments.

Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. If an excessively large value is specified as the starting index for an array in `_abi_decode`, it can cause the read position to overflow. This results in the decoding of values outside the intended array bounds, potentially leading to exploitations in contracts that use arrays within `_abi_decode`. This vulnerability affects 0.3.10 and earlier versions.

Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. When using the built-in `extract32(b, start)`, if the `start` index provided has for side effect to update `b`, the byte array to extract `32` bytes from, it could be that some dirty memory is read and returned by `extract32`. This vulnerability is fixed in 0.4.0.

An issue in the anchors subparser of Showdownjs versions

Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: Fix a potential use after free<br /> <br /> Free the adap structure only after we are done using it.<br /> This patch just moves the put_device() down a bit to avoid the<br /> use after free.<br /> <br /> [wsa: added comment to the code, added Fixes tag]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: usbhid: fix info leak in hid_submit_ctrl<br /> <br /> In hid_submit_ctrl(), the way of calculating the report length doesn&amp;#39;t<br /> take into account that report-&gt;size can be zero. When running the<br /> syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to<br /> calculate transfer_buffer_length as 16384. When this urb is passed to<br /> the usb core layer, KMSAN reports an info leak of 16384 bytes.<br /> <br /> To fix this, first modify hid_report_len() to account for the zero<br /> report size case by using DIV_ROUND_UP for the division. Then, call it<br /> from hid_submit_ctrl().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests<br /> <br /> hfi1 user SDMA request processing has two bugs that can cause data<br /> corruption for user SDMA requests that have multiple payload iovecs<br /> where an iovec other than the tail iovec does not run up to the page<br /> boundary for the buffer pointed to by that iovec.a<br /> <br /> Here are the specific bugs:<br /> 1. user_sdma_txadd() does not use struct user_sdma_iovec-&gt;iov.iov_len.<br /> Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec<br /> to the packet, even if some of those bytes are past<br /> iovec-&gt;iov.iov_len and are thus not intended to be in the packet.<br /> 2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the<br /> next iovec in user_sdma_request-&gt;iovs when the current iovec<br /> is not PAGE_SIZE and does not contain enough data to complete the<br /> packet. The transmitted packet will contain the wrong data from the<br /> iovec pages.<br /> <br /> This has not been an issue with SDMA packets from hfi1 Verbs or PSM2<br /> because they only produce iovecs that end short of PAGE_SIZE as the tail<br /> iovec of an SDMA request.<br /> <br /> Fixing these bugs exposes other bugs with the SDMA pin cache<br /> (struct mmu_rb_handler) that get in way of supporting user SDMA requests<br /> with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So<br /> this commit fixes those issues as well.<br /> <br /> Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec<br /> payload user SDMA requests can hit:<br /> 1. Overlapping memory ranges in mmu_rb_handler will result in duplicate<br /> pinnings.<br /> 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node),<br /> the mmu_rb code (1) removes the existing entry under a lock, (2)<br /> releases that lock, pins the new pages, (3) then reacquires the lock<br /> to insert the extended mmu_rb_node.<br /> <br /> If someone else comes in and inserts an overlapping entry between (2)<br /> and (3), insert in (3) will fail.<br /> <br /> The failure path code in this case unpins _all_ pages in either the<br /> original mmu_rb_node or the new mmu_rb_node that was inserted between<br /> (2) and (3).<br /> 3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node-&gt;refcount is<br /> incremented outside of mmu_rb_handler-&gt;lock. As a result, mmu_rb_node<br /> could be evicted by another thread that gets mmu_rb_handler-&gt;lock and<br /> checks mmu_rb_node-&gt;refcount before mmu_rb_node-&gt;refcount is<br /> incremented.<br /> 4. Related to #2 above, SDMA request submission failure path does not<br /> check mmu_rb_node-&gt;refcount before freeing mmu_rb_node object.<br /> <br /> If there are other SDMA requests in progress whose iovecs have<br /> pointers to the now-freed mmu_rb_node(s), those pointers to the<br /> now-freed mmu_rb nodes will be dereferenced when those SDMA requests<br /> complete.

Rejected reason: This CVE is a duplicate of CVE-2024-1631.

libming 0.4.8 contains a memory leak vulnerability in /libming/src/actioncompiler/listaction.c.

OpenDMARC 1.4.2 contains a null pointer dereference vulnerability in /OpenDMARC/libopendmarc/opendmarc_policy.c.