Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmasm: fix OOB reads in command_file_write due to missing size checks<br /> <br /> The command_file_write() handler allocates a kernel buffer of exactly<br /> count bytes and copies user data into it, but does not validate the<br /> buffer against the dot command protocol before passing it to<br /> get_dot_command_size() and get_dot_command_timeout().<br /> <br /> Since both the allocation size (count) and the header fields (command_size,<br /> data_size) are independently user-controlled, an attacker can cause<br /> get_dot_command_size() to return a value exceeding the allocation,<br /> triggering OOB reads in get_dot_command_timeout() and an out-of-bounds<br /> memcpy_toio() that leaks kernel heap memory to the service processor.<br /> <br /> Fix with two guards: reject writes smaller than sizeof(struct<br /> dot_command_header) before allocation, then after copying user data<br /> reject commands where the buffer is smaller than the total size declared<br /> by the header (sizeof(header) + command_size + data_size). This ensures<br /> all subsequent header and payload field accesses stay within the buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slub: fix data loss and overflow in krealloc()<br /> <br /> Commit 2cd8231796b5 ("mm/slub: allow to set node and align in<br /> k[v]realloc") introduced the ability to force a reallocation if the<br /> original object does not satisfy new alignment or NUMA node, even when<br /> the object is being shrunk.<br /> <br /> This introduced two bugs in the reallocation fallback path:<br /> <br /> 1. Data loss during NUMA migration: The jump to &amp;#39;alloc_new&amp;#39; happens<br /> before &amp;#39;ks&amp;#39; and &amp;#39;orig_size&amp;#39; are initialized. As a result, the<br /> memcpy() in the &amp;#39;alloc_new&amp;#39; block would copy 0 bytes into the new<br /> allocation.<br /> <br /> 2. Buffer overflow during shrinking: When shrinking an object while<br /> forcing a new alignment, &amp;#39;new_size&amp;#39; is smaller than the old size.<br /> However, the memcpy() used the old size (&amp;#39;orig_size ?: ks&amp;#39;), leading<br /> to an out-of-bounds write.<br /> <br /> The same overflow bug exists in the kvrealloc() fallback path, where the<br /> old bucket size ksize(p) is copied into the new buffer without being<br /> bounded by the new size.<br /> <br /> A simple reproducer:<br /> <br /> // e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW<br /> while (1) {<br /> void *p = kmalloc(128, GFP_KERNEL);<br /> p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE);<br /> kfree(p);<br /> }<br /> <br /> demonstrates the issue:<br /> <br /> ==================================================================<br /> BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130<br /> <br /> Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):<br /> memcpy_orig+0x68/0x130<br /> krealloc_node_align_noprof+0x1c8/0x340<br /> lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm]<br /> lkdtm_do_action+0x3a/0x60 [lkdtm]<br /> ...<br /> <br /> kfence-#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64<br /> <br /> allocated by task 316 on cpu 7 at 97.680481s (0.021813s ago):<br /> krealloc_node_align_noprof+0x19c/0x340<br /> lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm]<br /> lkdtm_do_action+0x3a/0x60 [lkdtm]<br /> ...<br /> ==================================================================<br /> <br /> Fix it by moving the old size calculation to the top of __do_krealloc()<br /> and bounding all copy lengths by the new allocation size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: unittest: fix use-after-free in testdrv_probe()<br /> <br /> The function testdrv_probe() retrieves the device_node from the PCI<br /> device, applies an overlay, and then immediately calls of_node_put(dn).<br /> This releases the reference held by the PCI core, potentially freeing<br /> the node if the reference count drops to zero. Later, the same freed<br /> pointer &amp;#39;dn&amp;#39; is passed to of_platform_default_populate(), leading to a<br /> use-after-free.<br /> <br /> The reference to pdev-&gt;dev.of_node is owned by the device model and<br /> should not be released by the driver. Remove the erroneous of_node_put()<br /> to prevent premature freeing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix re-decryption of RESPONSE packets<br /> <br /> If a RESPONSE packet gets a temporary failure during processing, it may end<br /> up in a partially decrypted state - and then get requeued for a retry.<br /> <br /> Fix this by just discarding the packet; we will send another CHALLENGE<br /> packet and thereby elicit a further response. Similarly, discard an<br /> incoming CHALLENGE packet if we get an error whilst generating a RESPONSE;<br /> the server will send another CHALLENGE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2<br /> <br /> After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs<br /> fields written by the CPU from vmcb02 to the cached vmcb12. This is<br /> because the cached vmcb12 is used as the authoritative copy of some of<br /> the controls, and is the payload when saving/restoring nested state.<br /> <br /> int_state is also written by the CPU, specifically bit 0 (i.e.<br /> SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync&amp;#39;d to<br /> cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE<br /> preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow<br /> would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites<br /> what KVM_SET_NESTED_STATE restored in int_state).<br /> <br /> However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an<br /> interrupt shadow would be restored into vmcb01 instead of vmcb02. This<br /> would mostly be benign for L1 (delays an interrupt), but not for L2. For<br /> L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before<br /> a HLT that should have been in an interrupt shadow).<br /> <br /> Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02()<br /> to avoid this problem. With that, KVM_SET_NESTED_STATE restores the<br /> correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it<br /> would overwrite it with the same value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: fix partition descriptor append bookkeeping<br /> <br /> Mounting a crafted UDF image with repeated partition descriptors can<br /> trigger a heap out-of-bounds write in part_descs_loc[].<br /> <br /> handle_partition_descriptor() deduplicates entries by partition number,<br /> but appended slots never record partnum. As a result duplicate<br /> Partition Descriptors are appended repeatedly and num_part_descs keeps<br /> growing.<br /> <br /> Once the table is full, the growth path still sizes the allocation from<br /> partnum even though inserts are indexed by num_part_descs. If partnum is<br /> already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep<br /> the old capacity and the next append writes past the end of the table.<br /> <br /> Store partnum in the appended slot and size growth from the next append<br /> count so deduplication and capacity tracking follow the same model.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Add spectre boundry for syscall dispatch table<br /> <br /> The LoongArch syscall number is directly controlled by userspace, but<br /> does not have a array_index_nospec() boundry to prevent access past the<br /> syscall function pointer tables.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: never defer requests during idmap lookup<br /> <br /> During v4 request compound arg decoding, some ops (e.g. SETATTR)<br /> can trigger idmap lookup upcalls. When those upcall responses get<br /> delayed beyond the allowed time limit, cache_check() will mark the<br /> request for deferral and cause it to be dropped.<br /> <br /> This prevents nfs4svc_encode_compoundres from being executed, and<br /> thus the session slot flag NFSD4_SLOT_INUSE never gets cleared.<br /> Subsequent client requests will fail with NFSERR_JUKEBOX, given<br /> that the slot will be marked as in-use, making the SEQUENCE op<br /> fail.<br /> <br /> Fix this by making sure that the RQ_USEDEFERRAL flag is always<br /> clear during nfs4svc_decode_compoundargs(), since no v4 request<br /> should ever be deferred.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch()<br /> <br /> Cover a missed execution path with a new check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/cio: Fix device lifecycle handling in css_alloc_subchannel()<br /> <br /> `css_alloc_subchannel()` calls `device_initialize()` before setting up<br /> the DMA masks. If `dma_set_coherent_mask()` or `dma_set_mask()` fails,<br /> the error path frees the subchannel structure directly, bypassing<br /> the device model reference counting.<br /> <br /> Once `device_initialize()` has been called, the embedded struct device<br /> must be released via `put_device()`, allowing the release callback to<br /> free the container structure.<br /> <br /> Fix the error path by dropping the initial device reference with<br /> `put_device()` instead of calling `kfree()` directly.<br /> <br /> This ensures correct device lifetime handling and avoids potential<br /> use-after-free or double-free issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Stop job scheduling across aie2_release_resource()<br /> <br /> Running jobs on a hardware context while it is in the process of<br /> releasing resources can lead to use-after-free and crashes.<br /> <br /> Fix this by stopping job scheduling before calling<br /> aie2_release_resource() and restarting it after the release completes.<br /> Additionally, aie2_sched_job_run() now checks whether the hardware<br /> context is still active.