In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: error damos_commit_quota_goal() for zero target_value Patch series "mm/damon: move zero damos quota target_value handling to the core layer". Having zero DAMOS quota target value can cause division by zero. DAMON API callers are checking the target value parameters to avoid that. It is easy to make mistakes in some of the multiple API callers. Move that to the core layer. Patch 1 adds the corner case handling into the core layer DAMON parameters validation logic. Patches 2 and 3 remove no more needed DAMON API callers side handling of the corner case in DAMON_LRU_SORT and DMON_SAMPLIE_MTIER, respectively. This patch (of 3): If a DAMOS scheme has a damos_quota_goal of zero target_value, damos_quota_goal() could trigger division-by-zero error. Hence each DAMON API callers should do the zero target_value validation. It is easy to make mistakes. Actually such bugs in DAMON_LRU_SORT and DAMON_SAMPLE_MTIER were found and fixed [1]. It is better to handle the corner case only once in the core layer, instead of multiple places in all DAMON API callers. One straightforward option is using an alternative denominator for the corner case in the damos_quota_goal(). However, the zero target_value is meaningless. In this case, the quota goal is always evaluated as achieved or over-achieved. The quota will only keep being reduced. Simply avoid using zero target_value by adding a check in the core layer DAMOS quota goal parameters validation/commit path, damos_commit_quota_goal(). Update it to return an error in the case. Also update its caller to propagate the error.
In the Linux kernel, the following vulnerability has been resolved: keys: Avoid the owner account dereference in named keyring lookup Named keyring lookup must keep the storage containing the owner UID alive through the namespace mapping check. find_keyring_by_name() reads keyring->user->uid under keyring_name_lock, but that lock protects the keyring's name entry and allocation, not its separate key_user. A named session-keyring join can overlap a privileged KEYCTL_CHOWN on another CPU. If the keyring holds the last reference to its old dynamic key_user and the ownership transfer succeeds, the following ordering is possible: Named join Chown find_keyring_by_name() keyctl_chown_key() read_lock(keyring_name_lock) down_write(key->sem) load old keyring->user replace key->user and key->uid up_write(key->sem) key_put(key) key_user_put(old user): free read old user->uid read_unlock(keyring_name_lock) Chown neither takes keyring_name_lock nor key_session_mutex, so it can free the old account between the pointer load and the UID read. The lookup then reads freed memory even though the keyring itself is alive. Use keyring->uid for the mapping check. key_alloc() initializes this inline owner UID and keyctl_chown_key() updates it on chown. The existing name lock keeps its containing keyring allocated throughout the check, so lookup no longer depends on the account's lifetime. This also matches the owner UID used by the permission check. KASAN report as below: BUG: KASAN: slab-use-after-free in find_keyring_by_name+0x577/0x5d0 Read of size 4 at addr ffff8881128ae2ec by task keycase/500
In the Linux kernel, the following vulnerability has been resolved: keys: make keyring indexes independent of kernel addresses KEYCTL_READ returns the serial numbers in a keyring in associative-array traversal order. The first word of the index is a public, deterministic hash of the type pointer, domain pointer and description. An unprivileged user can therefore insert keys with known descriptions, predict their order for each possible KASLR slide, and recover the kernel image address. On an x86-64 build with 16 MiB alignment, 45 user keys suffice to distinguish the candidate slides. Remove the addresses from the whole index, not just its first hash word. Assign each key type and domain a nonzero 64-bit ID and hash those IDs and the description with a once-initialized SipHash key. Use the full IDs in the later index chunks as well. Truncating or hashing the IDs there would lose the guarantee that distinct type/domain/description tuples have a differing index bit. Allocate IDs lazily since private key types need not be registered. Cache them in the index key so tree walks and copies of an existing index do not need to dereference a type descriptor that may have been unregistered. Keep the 32-bit chunk layout and diff_objects() bit offsets consistent, and retain the separate root slot for keyrings used by recursive search. The key comparison, permissions and userspace data format are unchanged; only the address-dependent in-memory ordering is replaced.
In the Linux kernel, the following vulnerability has been resolved: coredump: hold RCU while releasing parked threads coredump_finish() releases the parked threads by clearing ->task in their core_thread entry and calling wake_up_process() on each of them. It does that without holding a reference on the task and without being inside rcu. But calling wake_up_process(task) without rcu here isn't safe. A parked thread doesn't need that wakeup to leave. A spurious wakeup or a preemption after the store is enough for the task to go away. So if the coredump client is preempted between the store and wake_up_process() the thread can exit and be freed in the meantime and try_to_wake_up() takes pi_lock in freed memory. Hold rcu across the loop.
python-jose versions through 3.5.0 have an authentication bypass vulnerability due to acceptance of zero-length HMAC secrets in HMACKey and CryptographyHMACKey. This allows unauthenticated attackers to forge JWTs with arbitrary claims if the verification key resolves to empty, such as an oct JWK with an empty key value.
Kvazaar versions up to 2.3.2 have an infinite loop vulnerability in the read_header() function within src/encmain.c. This flaw allows an attacker to hang the command-line encoder by supplying a crafted truncated Y4M header file missing a terminating newline. The process enters an unchecked EOF read loop, consuming a full CPU core indefinitely and causing a denial of service.
libaec versions through 1.1.7 contain an out-of-bounds read vulnerability in the m_se_decode() function. This flaw allows attackers to bypass a signed bounds check by supplying a crafted CCSDS 121.0/SZIP stream with a large number of zero bits, potentially causing the decoder to crash or leak adjacent memory into decoded samples.
A vulnerability in rapidyaml versions up to 0.16.0 allows an out-of-bounds write in the ParseEngine::_add_annotation() function. This occurs when YAML input contains excessive consecutive anchors or tags, causing overflow of a fixed-size annotation array. The overflow can corrupt stack memory and crash the process.
The Sleuth Kit up to version 4.15.0 contains a NULL pointer dereference vulnerability in the decmpfs_decompress_lzvn_attr() function. This flaw can be triggered by supplying a crafted HFS+ image with a large uncompressed_size in an LZVN inline com.apple.decmpfs attribute, causing a denial of service by crashing the tool.
The Sleuth Kit through version 4.15.0 has a heap out-of-bounds read vulnerability in the hfs_load_extended_attrs() function. This flaw occurs because the function reads the decmpfs header without verifying the attribute length, allowing crafted HFS+ images with specific attribute sizes to cause out-of-bounds reads. This can lead to crashes in forensic analysis tools such as istat or icat.
libgphoto2 versions up to 2.5.34 contain a heap out-of-bounds read and write vulnerability in the jl2005bcd_decompress() function. This flaw allows malicious USB cameras to corrupt heap memory by exploiting oversized thumbnail processing. Specifically, attackers can manipulate allocation-table values and thumbnail header bytes to cause in-place byte-swapping to exceed the buffer by approximately 30 KB, potentially leaking heap contents in preview images. The vulnerability has a medium severity rating with a CVSS score of 5.4.
libgphoto2 versions up to 2.5.34 contain stack-based and heap-based buffer overflow vulnerabilities in the jl2005c_init() function. These vulnerabilities allow malicious USB devices, specifically spoofed Jeilin JL2005B/C/D cameras reporting 1022 or more allocation table entries, to corrupt memory. This corruption can overwrite the saved return address and heap data, potentially enabling code execution.
QuickJS-NG versions before 0.16.0 have a memory leak vulnerability in the js_atomics_store() function. This flaw occurs when the function fails to free a converted value upon returning a RangeError. An attacker running JavaScript can exploit this by repeatedly calling Atomics.store with a crafted valueOf that detaches or shrinks the buffer, leading to heap memory exhaustion and denial of service.
QuickJS-NG versions before 0.16.0 have an integer overflow vulnerability in the js_typed_array_sort() function. This flaw allows attackers who can execute JavaScript to trigger a heap buffer overflow on 32-bit systems by calling TypedArray.prototype.sort with a comparator on very large typed arrays near 2^30 elements. The overflow can cause crashes or potentially enable code execution.
QuickJS-NG versions before 0.16.0 have an integer overflow vulnerability in the js_proxy_get_own_property_names() function that leads to a heap buffer overflow on 32-bit systems. This occurs when JavaScript code returns a large array-like object from a Proxy ownKeys trap, causing the allocation size to wrap. The flaw can result in crashes or potentially allow code execution.
Netpbm versions before 10.86.51, 11.x before 11.02.30, and 11.03 before 11.15.08 have an out-of-bounds read vulnerability in the tgatoppm converter. This flaw occurs when the get_pixel() function uses unchecked pixel values as color map indexes, allowing crafted Targa files with pixel values exceeding color map bounds to cause a crash or leak adjacent memory.
Netpbm versions before 10.86.51, 11.x before 11.02.30, and 11.03 before 11.15.08 contain an integer overflow vulnerability in the jbigtopnm component. This flaw causes a heap buffer overflow when calculating the output buffer size. An attacker can exploit this by supplying a crafted multi-plane JBIG file with large header dimensions, leading to a buffer overflow in jbg_dec_merge_planes(), potentially causing application crashes or arbitrary code execution.
Netpbm versions before 10.86.51, 11.x before 11.02.30, and 11.03 before 11.15.08 contain a heap buffer overflow vulnerability in the xpmtoppm tool. This flaw arises from improper validation of the characters-per-pixel value in the XPM header, allowing attackers to supply crafted XPM files with values greater than 3. Exploitation can lead to application crashes or potentially arbitrary code execution.
Netpbm versions before 10.86.51, 11.x before 11.02.30, and 11.03 before 11.15.08 contain a stack-based buffer overflow vulnerability in the picttoppm utility's scanPoly() function. This flaw occurs when processing a crafted PICT file with polygon edges exceeding 5000 points, which can overflow the coordinate stack array, potentially causing a crash or arbitrary code execution.
Netpbm versions before 10.86.51, 11.x before 11.02.30, and 11.03 before 11.15.08 contain a stack-based buffer overflow vulnerability in the picttoppm paintPoly() function. This flaw arises from an unbounded polygon point count, allowing attackers to supply a crafted PICT file with a polygon exceeding 100 points. Exploitation can lead to application crashes or potentially arbitrary code execution.