Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/apic: Disable x2apic on resume if the kernel expects so<br /> <br /> When resuming from s2ram, firmware may re-enable x2apic mode, which may have<br /> been disabled by the kernel during boot either because it doesn&amp;#39;t support IRQ<br /> remapping or for other reasons. This causes the kernel to continue using the<br /> xapic interface, while the hardware is in x2apic mode, which causes hangs.<br /> This happens on defconfig + bare metal + s2ram.<br /> <br /> Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be<br /> disabled, i.e. when x2apic_mode = 0.<br /> <br /> The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the<br /> pre-sleep configuration or initial boot configuration for each CPU, including<br /> MSR state:<br /> <br /> When executing from the power-on reset vector as a result of waking from an<br /> S2 or S3 sleep state, the platform firmware performs only the hardware<br /> initialization required to restore the system to either the state the<br /> platform was in prior to the initial operating system boot, or to the<br /> pre-sleep configuration state. In multiprocessor systems, non-boot<br /> processors should be placed in the same state as prior to the initial<br /> operating system boot.<br /> <br /> (further ahead)<br /> <br /> If this is an S2 or S3 wake, then the platform runtime firmware restores<br /> minimum context of the system before jumping to the waking vector. This<br /> includes:<br /> <br /> CPU configuration. Platform runtime firmware restores the pre-sleep<br /> configuration or initial boot configuration of each CPU (MSR, MTRR,<br /> firmware update, SMBase, and so on). Interrupts must be disabled (for<br /> IA-32 processors, disabled by CLI instruction).<br /> <br /> (and other things)<br /> <br /> So at least as per the spec, re-enablement of x2apic by the firmware is<br /> allowed if "x2apic on" is a part of the initial boot configuration.<br /> <br /> [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization<br /> <br /> [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fix NULL pointer dereference in ublk_ctrl_set_size()<br /> <br /> ublk_ctrl_set_size() unconditionally dereferences ub-&gt;ub_disk via<br /> set_capacity_and_notify() without checking if it is NULL.<br /> <br /> ub-&gt;ub_disk is NULL before UBLK_CMD_START_DEV completes (it is only<br /> assigned in ublk_ctrl_start_dev()) and after UBLK_CMD_STOP_DEV runs<br /> (ublk_detach_disk() sets it to NULL). Since the UBLK_CMD_UPDATE_SIZE<br /> handler performs no state validation, a user can trigger a NULL pointer<br /> dereference by sending UPDATE_SIZE to a device that has been added but<br /> not yet started, or one that has been stopped.<br /> <br /> Fix this by checking ub-&gt;ub_disk under ub-&gt;mutex before dereferencing<br /> it, and returning -ENODEV if the disk is not available.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix undersized l_iclog_roundoff values<br /> <br /> If the superblock doesn&amp;#39;t list a log stripe unit, we set the incore log<br /> roundoff value to 512. This leads to corrupt logs and unmountable<br /> filesystems in generic/617 on a disk with 4k physical sectors...<br /> <br /> XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c<br /> XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197.<br /> XFS (sda1): failed to locate log tail<br /> XFS (sda1): log mount/recovery failed: error -74<br /> XFS (sda1): log mount failed<br /> XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c<br /> XFS (sda1): Ending clean mount<br /> <br /> ...on the current xfsprogs for-next which has a broken mkfs. xfs_info<br /> shows this...<br /> <br /> meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks<br /> = sectsz=4096 attr=2, projid32bit=1<br /> = crc=1 finobt=1, sparse=1, rmapbt=1<br /> = reflink=1 bigtime=1 inobtcount=1 nrext64=1<br /> = exchange=1 metadir=1<br /> data = bsize=4096 blocks=2579968, imaxpct=25<br /> = sunit=0 swidth=0 blks<br /> naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1<br /> log =internal log bsize=4096 blocks=16384, version=2<br /> = sectsz=4096 sunit=0 blks, lazy-count=1<br /> realtime =none extsz=4096 blocks=0, rtextents=0<br /> = rgcount=0 rgsize=268435456 extents<br /> = zoned=0 start=0 reserved=0<br /> <br /> ...observe that the log section has sectsz=4096 sunit=0, which means<br /> that the roundoff factor is 512, not 4096 as you&amp;#39;d expect. We should<br /> fix mkfs not to generate broken filesystems, but anyone can fuzz the<br /> ondisk superblock so we should be more cautious. I think the inadequate<br /> logic predates commit a6a65fef5ef8d0, but that&amp;#39;s clearly going to<br /> require a different backport.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/kbuf: check if target buffer list is still legacy on recycle<br /> <br /> There&amp;#39;s a gap between when the buffer was grabbed and when it<br /> potentially gets recycled, where if the list is empty, someone could&amp;#39;ve<br /> upgraded it to a ring provided type. This can happen if the request<br /> is forced via io-wq. The legacy recycling is missing checking if the<br /> buffer_list still exists, and if it&amp;#39;s of the correct type. Add those<br /> checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Fix a few more NULL pointer dereference in device cleanup<br /> <br /> I found a few more paths that cleanup fails due to a NULL version pointer<br /> on unsupported hardware.<br /> <br /> Add NULL checks as applicable.<br /> <br /> (cherry picked from commit f5a05f8414fc10f307eb965f303580c7778f8dd2)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix potential overflow of shmem scatterlist length<br /> <br /> When a scatterlists table of a GEM shmem object of size 4 GB or more is<br /> populated with pages allocated from a folio, unsigned int .length<br /> attribute of a scatterlist may get overflowed if total byte length of<br /> pages allocated to that single scatterlist happens to reach or cross the<br /> 4GB limit. As a consequence, users of the object may suffer from hitting<br /> unexpected, premature end of the object&amp;#39;s backing pages.<br /> <br /> [278.780187] ------------[ cut here ]------------<br /> [278.780377] WARNING: CPU: 1 PID: 2326 at drivers/gpu/drm/i915/i915_mm.c:55 remap_sg+0x199/0x1d0 [i915]<br /> ...<br /> [278.780654] CPU: 1 UID: 0 PID: 2326 Comm: gem_mmap_offset Tainted: G S U 6.17.0-rc1-CI_DRM_16981-ged823aaa0607+ #1 PREEMPT(voluntary)<br /> [278.780656] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER<br /> [278.780658] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024<br /> [278.780659] RIP: 0010:remap_sg+0x199/0x1d0 [i915]<br /> ...<br /> [278.780786] Call Trace:<br /> [278.780787] <br /> [278.780788] ? __apply_to_page_range+0x3e6/0x910<br /> [278.780795] ? __pfx_remap_sg+0x10/0x10 [i915]<br /> [278.780906] apply_to_page_range+0x14/0x30<br /> [278.780908] remap_io_sg+0x14d/0x260 [i915]<br /> [278.781013] vm_fault_cpu+0xd2/0x330 [i915]<br /> [278.781137] __do_fault+0x3a/0x1b0<br /> [278.781140] do_fault+0x322/0x640<br /> [278.781143] __handle_mm_fault+0x938/0xfd0<br /> [278.781150] handle_mm_fault+0x12c/0x300<br /> [278.781152] ? lock_mm_and_find_vma+0x4b/0x760<br /> [278.781155] do_user_addr_fault+0x2d6/0x8e0<br /> [278.781160] exc_page_fault+0x96/0x2c0<br /> [278.781165] asm_exc_page_fault+0x27/0x30<br /> ...<br /> <br /> That issue was apprehended by the author of a change that introduced it,<br /> and potential risk even annotated with a comment, but then never addressed.<br /> <br /> When adding folio pages to a scatterlist table, take care of byte length<br /> of any single scatterlist not exceeding max_segment.<br /> <br /> (cherry picked from commit 06249b4e691a75694c014a61708c007fb5755f60)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Fix NULL pointer dereference in device cleanup<br /> <br /> When GPU initialization fails due to an unsupported HW block<br /> IP blocks may have a NULL version pointer. During cleanup in<br /> amdgpu_device_fini_hw, the code calls amdgpu_device_set_pg_state and<br /> amdgpu_device_set_cg_state which iterate over all IP blocks and access<br /> adev-&gt;ip_blocks[i].version without NULL checks, leading to a kernel<br /> NULL pointer dereference.<br /> <br /> Add NULL checks for adev-&gt;ip_blocks[i].version in both<br /> amdgpu_device_set_cg_state and amdgpu_device_set_pg_state to prevent<br /> dereferencing NULL pointers during GPU teardown when initialization has<br /> failed.<br /> <br /> (cherry picked from commit b7ac77468cda92eecae560b05f62f997a12fe2f2)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: mipi-i3c-hci: Fix race in DMA ring dequeue<br /> <br /> The HCI DMA dequeue path (hci_dma_dequeue_xfer()) may be invoked for<br /> multiple transfers that timeout around the same time. However, the<br /> function is not serialized and can race with itself.<br /> <br /> When a timeout occurs, hci_dma_dequeue_xfer() stops the ring, processes<br /> incomplete transfers, and then restarts the ring. If another timeout<br /> triggers a parallel call into the same function, the two instances may<br /> interfere with each other - stopping or restarting the ring at unexpected<br /> times.<br /> <br /> Add a mutex so that hci_dma_dequeue_xfer() is serialized with respect to<br /> itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: proximity: hx9023s: Protect against division by zero in set_samp_freq<br /> <br /> Avoid division by zero when sampling frequency is unspecified.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: imu: adis: Fix NULL pointer dereference in adis_init<br /> <br /> The adis_init() function dereferences adis-&gt;ops to check if the<br /> individual function pointers (write, read, reset) are NULL, but does<br /> not first check if adis-&gt;ops itself is NULL.<br /> <br /> Drivers like adis16480, adis16490, adis16545 and others do not set<br /> custom ops and rely on adis_init() assigning the defaults. Since struct<br /> adis is zero-initialized by devm_iio_device_alloc(), adis-&gt;ops is NULL<br /> when adis_init() is called, causing a NULL pointer dereference:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> pc : adis_init+0xc0/0x118<br /> Call trace:<br /> adis_init+0xc0/0x118<br /> adis16480_probe+0xe0/0x670<br /> <br /> Fix this by checking if adis-&gt;ops is NULL before dereferencing it,<br /> falling through to assign the default ops in that case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gyro: mpu3050-core: fix pm_runtime error handling<br /> <br /> The return value of pm_runtime_get_sync() is not checked, allowing<br /> the driver to access hardware that may fail to resume. The device<br /> usage count is also unconditionally incremented. Use<br /> pm_runtime_resume_and_get() which propagates errors and avoids<br /> incrementing the usage count on failure.<br /> <br /> In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate()<br /> failure since postdisable does not run when preenable fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: add missing RCU unlock in error path in try_release_subpage_extent_buffer()<br /> <br /> Call rcu_read_lock() before exiting the loop in<br /> try_release_subpage_extent_buffer() because there is a rcu_read_unlock()<br /> call past the loop.<br /> <br /> This has been detected by the Clang thread-safety analyzer.