Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - validate RSA CRT component lengths<br /> <br /> The generic RSA key parser (rsa_helper.c) bounds each CRT component (p,<br /> q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt()<br /> allocates half-size DMA buffers (key_sz / 2) and right-aligns each<br /> component with:<br /> <br /> memcpy(dst + half_key_sz - len, src, len)<br /> <br /> When a CRT component is larger than half_key_sz the subtraction<br /> underflows and memcpy writes past the DMA buffer, causing memory<br /> corruption.<br /> <br /> Add a len &gt; half_key_sz check next to the existing !len check for each<br /> of the five CRT components so the driver falls back to the non-CRT path<br /> instead of writing out of bounds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - protect service table iterations with service_lock<br /> <br /> The service_table list is protected by service_lock when entries are<br /> added or removed (in adf_service_add() and adf_service_remove()), but<br /> several functions iterate over the list without holding this lock.<br /> <br /> A concurrent adf_service_register() or adf_service_unregister() call<br /> could modify the list during traversal, leading to list corruption or<br /> a use-after-free.<br /> <br /> Fix this by holding service_lock across all list_for_each_entry()<br /> iterations of service_table in adf_dev_init(), adf_dev_start(),<br /> adf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(),<br /> adf_dev_restarted_notify(), and adf_error_notifier().<br /> <br /> The lock ordering is safe: callers of the static helpers (adf_dev_up()<br /> and adf_dev_down()) acquire state_lock before service_lock, and no<br /> event_hld callback or service_lock holder ever acquires state_lock in<br /> the reverse order.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: drbg - Fix returning success on failure in CTR_DRBG<br /> <br /> drbg_ctr_generate() sometimes returns success when it fails, leaving the<br /> output buffer uninitialized. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG)<br /> <br /> Sashiko notes:<br /> <br /> &gt; if SEV initialization fails and KVM is actively running normal VMs, could a<br /> &gt; userspace process trigger this code path via /dev/sev ioctls (e.g.,<br /> &gt; SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN<br /> &gt; execution for an active VM trigger a general protection fault and crash the<br /> &gt; host?<br /> <br /> Refuse to re-try initialization if SNP is not already initialized for<br /> SNP_CONFIG.<br /> <br /> This is technically an ABI break: before if SNP initialization failed it<br /> could be transparently retriggered by this ioctl, and if no VMs were<br /> running, everything worked fine. Hopefully this is enough of a corner case<br /> that nobody will notice, but someone does, there are a few options:<br /> <br /> * do something like symbol_get() for kvm and refuse to initialize if KVM is<br /> loaded<br /> * check each cpu&amp;#39;s HSAVE_PA for non-zero data before re-initializing<br /> * once initialization has failed, continue to refuse to initialize until<br /> the ccp module is unloaded

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD)<br /> <br /> Sashiko notes:<br /> <br /> &gt; if SEV initialization fails and KVM is actively running normal VMs, could a<br /> &gt; userspace process trigger this code path via /dev/sev ioctls (e.g.,<br /> &gt; SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN<br /> &gt; execution for an active VM trigger a general protection fault and crash the<br /> &gt; host?<br /> <br /> The SEV firmware docs for SNP_VLEK_LOAD note:<br /> <br /> &gt; On SNP_SHUTDOWN, the VLEK is deleted.<br /> <br /> That is, the initialization/shutdown wrapper here is pointless, because the<br /> firmware immediately throws away the key anyway. Instead, refuse to do<br /> anything if SNP has not been previously initialized.<br /> <br /> This is an ABI break: before, this was a no-op and almost certainly a<br /> mistake by userspace, and now it returns -ENODEV. ABI compatibility could be<br /> maintained here by simply returning 0 in the check instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Use sizeof(*hdr) instead of sizeof(hdr) in veventq read<br /> <br /> The bound-check in iommufd_veventq_fops_read() for the normal vEVENT<br /> path uses sizeof(hdr) where the surrounding code uses sizeof(*hdr):<br /> <br /> if (!vevent_for_lost_events_header(cur) &amp;&amp;<br /> sizeof(hdr) + cur-&gt;data_len &gt; count - done) {<br /> <br /> hdr is declared as struct iommufd_vevent_header *, so sizeof(hdr)<br /> evaluates to the size of the pointer. Surrounding code uses<br /> sizeof(*hdr) consistently:<br /> <br /> if (done &gt;= count || sizeof(*hdr) &gt; count - done) {<br /> ...<br /> if (copy_to_user(buf + done, hdr, sizeof(*hdr))) {<br /> ...<br /> done += sizeof(*hdr);<br /> <br /> struct iommufd_vevent_header is currently 8 bytes (two __u32 fields,<br /> flags and sequence), so on 64-bit (sizeof(void *) == 8) the two<br /> expressions happen to be equal and the check works as intended.<br /> <br /> On 32-bit (sizeof(void *) == 4) the check under-counts the header by<br /> 4 bytes: a vEVENT whose data_len causes 8 + cur-&gt;data_len to exceed<br /> count - done while 4 + cur-&gt;data_len does not will pass the check,<br /> then the loop will copy_to_user 8 bytes of header followed by data_len<br /> bytes of payload, writing past the user-supplied buffer.<br /> <br /> It is also a latent bug for any future expansion of struct<br /> iommufd_vevent_header beyond sizeof(void *) on 64-bit; the check<br /> should not depend on the type happening to match the host pointer<br /> width.<br /> <br /> Use sizeof(*hdr) to match the rest of the function and the actual<br /> amount that will be copied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: do file ownership checks with the proper mount idmap<br /> <br /> Ever since idmapped mounts were introduced, inode ownership checks (for<br /> side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done<br /> against the nop_mnt_idmap, which completely ignores the file&amp;#39;s mount&amp;#39;s<br /> idmap. This results in odd edgecases like:<br /> <br /> 1) mount/bind-mount with an idmap userA:userB:1<br /> 2) userB runs an owner_or_capable() check on file that is owned by userA<br /> on-disk/in-memory, but owned by userB after idmap translation<br /> 3) owner_or_capable() mysteriously fails as the correct idmap wasn&amp;#39;t supplied<br /> <br /> In the case of mincore/madvise MADV_PAGEOUT, this is usually benign,<br /> because file_permission(file, MAY_WRITE) will probably succeed, as it uses<br /> the proper idmap internally, but it does not need to be the case on e.g a<br /> 0444 file where even the owner itself doesn&amp;#39;t have permissions to write to<br /> it.<br /> <br /> Since this is clearly not trivial to get right, introduce a<br /> file_owner_or_capable() that can carry the correct semantics, and switch<br /> the various users in mm to it.<br /> <br /> The issue was found by manual code inspection &amp; an off-list discussion<br /> with Jan Kara.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access<br /> <br /> The page_ext iteration API does not validate if the PFN still belongs to a<br /> valid section while advancing the iterator. When dynamically adding<br /> memory in the hotplug path, it can lead to a NULL pointer dereference<br /> during page_ext_lookup at the boundary of the last valid section when<br /> iterator count equals __pgcount.<br /> <br /> The for_each_page_ext() macro calls page_ext_iter_next() as its loop<br /> increment. for_each_page_ext() does a "__page_ext =<br /> page_ext_iter_next(&amp;__iter)" at the end. This causes page_ext_iter_next()<br /> to increment iter-&gt;index past __pgcount and call page_ext_lookup(start_pfn<br /> + __pgcount). During memory hotplug (online), the PFN at start_pfn +<br /> __pgcount may belong to a section that has not yet been initialized,<br /> causing page_ext_lookup() to trigger a NULL pointer dereference.<br /> <br /> [ 14.555124][ T846] Call trace:<br /> [ 14.555125][ T846] lookup_page_ext+0x6c/0x108 (P)<br /> [ 14.555127][ T846] page_ext_lookup+0x30/0x3c<br /> [ 14.555129][ T846] __reset_page_owner+0x11c/0x260<br /> [ 14.571201][ T846] __free_pages_ok+0x5e8/0x8e0<br /> [ 14.571204][ T846] __free_pages_core+0x78/0xf0<br /> [ 14.571206][ T846] generic_online_page+0x14/0x24<br /> [ 14.597782][ T846] online_pages+0x178/0x30c<br /> [ 14.597784][ T846] memory_block_change_state+0x284/0x32c<br /> [ 14.597787][ T846] memory_subsys_online+0x4c/0x64<br /> [ 14.597789][ T846] device_online+0x88/0xb0<br /> [ 14.597791][ T846] online_memory_block+0x30/0x40<br /> [ 14.597793][ T846] walk_memory_blocks+0xac/0xe8<br /> [ 14.597794][ T846] add_memory_resource+0x280/0x298<br /> [ 14.656161][ T846] add_memory+0x60/0x98<br /> <br /> Move the iteration boundary enforcement inside the iterator functions, so<br /> callers cannot inadvertently access beyond the requested range.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: bound uniname advance in exfat_find_dir_entry()<br /> <br /> In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the<br /> output pointer by a fixed amount while the loop guard only tracks the<br /> accumulated name length:<br /> <br /> if (++order == 2)<br /> uniname = p_uniname-&gt;name;<br /> else<br /> uniname += EXFAT_FILE_NAME_LEN;<br /> len = exfat_extract_uni_name(ep, entry_uniname);<br /> name_len += len;<br /> unichar = *(uniname+len);<br /> *(uniname+len) = 0x0;<br /> <br /> uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len<br /> grows only by the actual extracted length, which is shorter when a name<br /> fragment contains an early NUL. The only guard is<br /> `name_len &gt;= MAX_NAME_LENGTH`, so a crafted directory with many short<br /> name fragments lets uniname run far past the<br /> p_uniname-&gt;name[MAX_NAME_LENGTH + 3] buffer while name_len stays small,<br /> causing an out-of-bounds read and write at *(uniname+len).<br /> <br /> The sibling extractor exfat_get_uniname_from_ext_entry() already stops<br /> on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard<br /> added in commit d42334578eba ("exfat: check if filename entries exceeds<br /> max filename length")); exfat_find_dir_entry() never got the<br /> equivalent. Track the per-entry write offset as a count and reject a<br /> fragment once the offset, or the offset plus the extracted length, would<br /> exceed MAX_NAME_LENGTH, before forming the output pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> module: decompress: check return value of module_extend_max_pages()<br /> <br /> module_extend_max_pages() calls kvrealloc() internally and returns<br /> -ENOMEM on allocation failure. The return value is never checked.<br /> <br /> If the initial allocation fails, info-&gt;pages remains NULL and<br /> info-&gt;max_pages remains 0. Subsequent calls to module_get_next_page()<br /> will attempt to dynamically grow the array by calling<br /> module_extend_max_pages(info, 0) since info-&gt;used_pages is 0. This<br /> results in kvrealloc(NULL, 0) returning ZERO_SIZE_PTR, which is treated<br /> as a success, leading to a dereference of ZERO_SIZE_PTR and a kernel<br /> oops.<br /> <br /> Fix: add the missing error check after module_extend_max_pages() and<br /> return immediately on failure. This matches the pattern used by every<br /> other kvrealloc() caller in the module loading path.<br /> <br /> [Sami: Corrected the analysis in the commit message.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: include MAY_WRITE in open permission mask for O_TRUNC<br /> <br /> POSIX requires write permission to truncate a file, so an open() that<br /> specifies O_TRUNC must be authorized for write access regardless of the<br /> O_ACCMODE access mode.<br /> <br /> nfs_open_permission_mask() builds the access mask passed to<br /> nfs_may_open(), which is the local authorization gate for OPENs the<br /> client serves itself from a cached write delegation via the<br /> can_open_delegated() path in nfs4_try_open_cached(). The mask is<br /> derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a<br /> file the caller cannot write requests only MAY_READ and passes the<br /> local check. The OPEN is then satisfied locally and the truncation is<br /> issued to the server as a SETATTR(size=0) over the delegation stateid,<br /> which the server accepts under standard write-delegation semantics.<br /> POSIX requires that this open fail with EACCES.<br /> <br /> Include MAY_WRITE in the mask whenever O_TRUNC is set so the local<br /> check matches the access the server would have enforced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Prevent out-of-bounds read in glob matching<br /> <br /> String event fields are not necessarily NUL-terminated, so the filter<br /> predicate functions (filter_pred_string(), filter_pred_strloc() and<br /> filter_pred_strrelloc()) pass the field length to the regex match<br /> callbacks, and the length-aware matchers honour it.<br /> <br /> regex_match_glob() was the exception: it ignored the length and called<br /> glob_match(), which scans the string until it hits a NUL byte. Some<br /> string fields are not NUL-terminated. One example is the dynamic char<br /> array of the xfs_* namespace tracepoints, which is copied without a<br /> trailing NUL. For such a field, glob matching reads past the end of<br /> the event field, causing a KASAN slab-out-of-bounds read in<br /> glob_match(), reached via regex_match_glob() and filter_match_preds()<br /> from the xfs_lookup tracepoint.<br /> <br /> Add a length-bounded glob_match_len() and use it from regex_match_glob()<br /> so glob matching always stops at the field boundary. The matching loop<br /> is factored into a shared helper so glob_match() keeps its behaviour.