Vulnerabilities

OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, when the `AuthType` is set to anything but `Basic`, if the request contains an `Authorization: Basic ...` header, the password is not checked. This results in authentication bypass. Any configuration that allows an `AuthType` that is not `Basic` is affected. Version 2.4.13 fixes the issue.

Insecure Direct Object Reference (IDOR) vulnerability in Liferay Portal 7.4.0 through 7.4.3.124, and Liferay DXP 2024.Q2.0 through 2024.Q2.7, 2024.Q1.1 through 2024.Q1.12, and 7.4 GA through update 92 allows remote authenticated users to access a workflow definition by name via the API

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: x86/aegis - Add missing error checks<br /> <br /> The skcipher_walk functions can allocate memory and can fail, so<br /> checking for errors is necessary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: dm-crypt: Do not partially accept write BIOs with zoned targets<br /> <br /> Read and write operations issued to a dm-crypt target may be split<br /> according to the dm-crypt internal limits defined by the max_read_size<br /> and max_write_size module parameters (default is 128 KB). The intent is<br /> to improve processing time of large BIOs by splitting them into smaller<br /> operations that can be parallelized on different CPUs.<br /> <br /> For zoned dm-crypt targets, this BIO splitting is still done but without<br /> the parallel execution to ensure that the issuing order of write<br /> operations to the underlying devices remains sequential. However, the<br /> splitting itself causes other problems:<br /> <br /> 1) Since dm-crypt relies on the block layer zone write plugging to<br /> handle zone append emulation using regular write operations, the<br /> reminder of a split write BIO will always be plugged into the target<br /> zone write plugged. Once the on-going write BIO finishes, this<br /> reminder BIO is unplugged and issued from the zone write plug work.<br /> If this reminder BIO itself needs to be split, the reminder will be<br /> re-issued and plugged again, but that causes a call to a<br /> blk_queue_enter(), which may block if a queue freeze operation was<br /> initiated. This results in a deadlock as DM submission still holds<br /> BIOs that the queue freeze side is waiting for.<br /> <br /> 2) dm-crypt relies on the emulation done by the block layer using<br /> regular write operations for processing zone append operations. This<br /> still requires to properly return the written sector as the BIO<br /> sector of the original BIO. However, this can be done correctly only<br /> and only if there is a single clone BIO used for processing the<br /> original zone append operation issued by the user. If the size of a<br /> zone append operation is larger than dm-crypt max_write_size, then<br /> the orginal BIO will be split and processed as a chain of regular<br /> write operations. Such chaining result in an incorrect written sector<br /> being returned to the zone append issuer using the original BIO<br /> sector. This in turn results in file system data corruptions using<br /> xfs or btrfs.<br /> <br /> Fix this by modifying get_max_request_size() to always return the size<br /> of the BIO to avoid it being split with dm_accpet_partial_bio() in<br /> crypt_map(). get_max_request_size() is renamed to<br /> get_max_request_sectors() to clarify the unit of the value returned<br /> and its interface is changed to take a struct dm_target pointer and a<br /> pointer to the struct bio being processed. In addition to this change,<br /> to ensure that crypt_alloc_buffer() works correctly, set the dm-crypt<br /> device max_hw_sectors limit to be at most<br /> BIO_MAX_VECS

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE<br /> <br /> On Google gs101, the number of UTP transfer request slots (nutrs) is 32,<br /> and in this case the driver ends up programming the UTRL_NEXUS_TYPE<br /> incorrectly as 0.<br /> <br /> This is because the left hand side of the shift is 1, which is of type<br /> int, i.e. 31 bits wide. Shifting by more than that width results in<br /> undefined behaviour.<br /> <br /> Fix this by switching to the BIT() macro, which applies correct type<br /> casting as required. This ensures the correct value is written to<br /> UTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shift<br /> warning:<br /> <br /> UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21<br /> shift exponent 32 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> <br /> For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPE<br /> write.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: host: Detect events pointing to unexpected TREs<br /> <br /> When a remote device sends a completion event to the host, it contains a<br /> pointer to the consumed TRE. The host uses this pointer to process all of<br /> the TREs between it and the host&amp;#39;s local copy of the ring&amp;#39;s read pointer.<br /> This works when processing completion for chained transactions, but can<br /> lead to nasty results if the device sends an event for a single-element<br /> transaction with a read pointer that is multiple elements ahead of the<br /> host&amp;#39;s read pointer.<br /> <br /> For instance, if the host accesses an event ring while the device is<br /> updating it, the pointer inside of the event might still point to an old<br /> TRE. If the host uses the channel&amp;#39;s xfer_cb() to directly free the buffer<br /> pointed to by the TRE, the buffer will be double-freed.<br /> <br /> This behavior was observed on an ep that used upstream EP stack without<br /> &amp;#39;commit 6f18d174b73d ("bus: mhi: ep: Update read pointer only after buffer<br /> is written")&amp;#39;. Where the device updated the events ring pointer before<br /> updating the event contents, so it left a window where the host was able to<br /> access the stale data the event pointed to, before the device had the<br /> chance to update them. The usual pattern was that the host received an<br /> event pointing to a TRE that is not immediately after the last processed<br /> one, so it got treated as if it was a chained transaction, processing all<br /> of the TREs in between the two read pointers.<br /> <br /> This commit aims to harden the host by ensuring transactions where the<br /> event points to a TRE that isn&amp;#39;t local_rp + 1 are chained.<br /> <br /> [mani: added stable tag and reworded commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/vmscape: Add conditional IBPB mitigation<br /> <br /> VMSCAPE is a vulnerability that exploits insufficient branch predictor<br /> isolation between a guest and a userspace hypervisor (like QEMU). Existing<br /> mitigations already protect kernel/KVM from a malicious guest. Userspace<br /> can additionally be protected by flushing the branch predictors after a<br /> VMexit.<br /> <br /> Since it is the userspace that consumes the poisoned branch predictors,<br /> conditionally issue an IBPB after a VMexit and before returning to<br /> userspace. Workloads that frequently switch between hypervisor and<br /> userspace will incur the most overhead from the new IBPB.<br /> <br /> This new IBPB is not integrated with the existing IBPB sites. For<br /> instance, a task can use the existing speculation control prctl() to<br /> get an IBPB at context switch time. With this implementation, the<br /> IBPB is doubled up: one at context switch and another before running<br /> userspace.<br /> <br /> The intent is to integrate and optimize these cases post-embargo.<br /> <br /> [ dhansen: elaborate on suboptimal IBPB solution ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Drop WARN_ON_ONCE() from flush_cache_vmap<br /> <br /> I have observed warning to occassionally trigger.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix link speed calculation on retrain failure<br /> <br /> When pcie_failed_link_retrain() fails to retrain, it tries to revert to the<br /> previous link speed. However it calculates that speed from the Link<br /> Control 2 register without masking out non-speed bits first.<br /> <br /> PCIE_LNKCTL2_TLS2SPEED() converts such incorrect values to<br /> PCI_SPEED_UNKNOWN (0xff), which in turn causes a WARN splat in<br /> pcie_set_target_speed():<br /> <br /> pci 0000:00:01.1: [1022:14ed] type 01 class 0x060400 PCIe Root Port<br /> pci 0000:00:01.1: broken device, retraining non-functional downstream link at 2.5GT/s<br /> pci 0000:00:01.1: retraining failed<br /> WARNING: CPU: 1 PID: 1 at drivers/pci/pcie/bwctrl.c:168 pcie_set_target_speed<br /> RDX: 0000000000000001 RSI: 00000000000000ff RDI: ffff9acd82efa000<br /> pcie_failed_link_retrain<br /> pci_device_add<br /> pci_scan_single_device<br /> <br /> Mask out the non-speed bits in PCIE_LNKCTL2_TLS2SPEED() and<br /> PCIE_LNKCAP_SLS2SPEED() so they don&amp;#39;t incorrectly return PCI_SPEED_UNKNOWN.<br /> <br /> [bhelgaas: commit log, add details from https://lore.kernel.org/r/1c92ef6bcb314ee6977839b46b393282e4f52e74.1750684771.git.lukas@wunner.de]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/hisilicon/hibmc: fix irq_request()&amp;#39;s irq name variable is local<br /> <br /> The local variable is passed in request_irq (), and there will be use<br /> after free problem, which will make request_irq failed. Using the global<br /> irq name instead of it to fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad7173: fix channels index for syscalib_mode<br /> <br /> Fix the index used to look up the channel when accessing the<br /> syscalib_mode attribute. The address field is a 0-based index (same<br /> as scan_index) that it used to access the channel in the<br /> ad7173_channels array throughout the driver. The channels field, on<br /> the other hand, may not match the address field depending on the<br /> channel configuration specified in the device tree and could result<br /> in an out-of-bounds access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: prevent softlockup in jbd2_log_do_checkpoint()<br /> <br /> Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()<br /> periodically release j_list_lock after processing a batch of buffers to<br /> avoid long hold times on the j_list_lock. However, since both functions<br /> contend for j_list_lock, the combined time spent waiting and processing<br /> can be significant.<br /> <br /> jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when<br /> need_resched() is true to avoid softlockups during prolonged operations.<br /> But jbd2_log_do_checkpoint() only exits its loop when need_resched() is<br /> true, relying on potentially sleeping functions like __flush_batch() or<br /> wait_on_buffer() to trigger rescheduling. If those functions do not sleep,<br /> the kernel may hit a softlockup.<br /> <br /> watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]<br /> CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10<br /> Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017<br /> Workqueue: writeback wb_workfn (flush-7:2)<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : native_queued_spin_lock_slowpath+0x358/0x418<br /> lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]<br /> Call trace:<br /> native_queued_spin_lock_slowpath+0x358/0x418<br /> jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]<br /> __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]<br /> add_transaction_credits+0x3bc/0x418 [jbd2]<br /> start_this_handle+0xf8/0x560 [jbd2]<br /> jbd2__journal_start+0x118/0x228 [jbd2]<br /> __ext4_journal_start_sb+0x110/0x188 [ext4]<br /> ext4_do_writepages+0x3dc/0x740 [ext4]<br /> ext4_writepages+0xa4/0x190 [ext4]<br /> do_writepages+0x94/0x228<br /> __writeback_single_inode+0x48/0x318<br /> writeback_sb_inodes+0x204/0x590<br /> __writeback_inodes_wb+0x54/0xf8<br /> wb_writeback+0x2cc/0x3d8<br /> wb_do_writeback+0x2e0/0x2f8<br /> wb_workfn+0x80/0x2a8<br /> process_one_work+0x178/0x3e8<br /> worker_thread+0x234/0x3b8<br /> kthread+0xf0/0x108<br /> ret_from_fork+0x10/0x20<br /> <br /> So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid<br /> softlockup.