Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: marvell: a3700-comphy: Fix out of bounds read<br /> <br /> There is an out of bounds read access of &amp;#39;gbe_phy_init_fix[fix_idx].addr&amp;#39;<br /> every iteration after &amp;#39;fix_idx&amp;#39; reaches &amp;#39;ARRAY_SIZE(gbe_phy_init_fix)&amp;#39;.<br /> <br /> Make sure &amp;#39;gbe_phy_init[addr]&amp;#39; is used when all elements of<br /> &amp;#39;gbe_phy_init_fix&amp;#39; array are handled.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: turn folio_test_hugetlb into a PageType<br /> <br /> The current folio_test_hugetlb() can be fooled by a concurrent folio split<br /> into returning true for a folio which has never belonged to hugetlbfs. <br /> This can&amp;#39;t happen if the caller holds a refcount on it, but we have a few<br /> places (memory-failure, compaction, procfs) which do not and should not<br /> take a speculative reference.<br /> <br /> Since hugetlb pages do not use individual page mapcounts (they are always<br /> fully mapped and use the entire_mapcount field to record the number of<br /> mappings), the PageType field is available now that page_mapcount()<br /> ignores the value in this field.<br /> <br /> In compaction and with CONFIG_DEBUG_VM enabled, the current implementation<br /> can result in an oops, as reported by Luis. This happens since 9c5ccf2db04b<br /> ("mm: remove HUGETLB_PAGE_DTOR") effectively added some VM_BUG_ON() checks<br /> in the PageHuge() testing path.<br /> <br /> [willy@infradead.org: update vmcoreinfo]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: uefisecapp: Fix memory related IO errors and crashes<br /> <br /> It turns out that while the QSEECOM APP_SEND command has specific fields<br /> for request and response buffers, uefisecapp expects them both to be in<br /> a single memory region. Failure to adhere to this has (so far) resulted<br /> in either no response being written to the response buffer (causing an<br /> EIO to be emitted down the line), the SCM call to fail with EINVAL<br /> (i.e., directly from TZ/firmware), or the device to be hard-reset.<br /> <br /> While this issue can be triggered deterministically, in the current form<br /> it seems to happen rather sporadically (which is why it has gone<br /> unnoticed during earlier testing). This is likely due to the two<br /> kzalloc() calls (for request and response) being directly after each<br /> other. Which means that those likely return consecutive regions most of<br /> the time, especially when not much else is going on in the system.<br /> <br /> Fix this by allocating a single memory region for both request and<br /> response buffers, properly aligning both structs inside it. This<br /> unfortunately also means that the qcom_scm_qseecom_app_send() interface<br /> needs to be restructured, as it should no longer map the DMA regions<br /> separately. Therefore, move the responsibility of DMA allocation (or<br /> mapping) to the caller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: CPPC: Use access_width over bit_width for system memory accesses<br /> <br /> To align with ACPI 6.3+, since bit_width can be any 8-bit value, it<br /> cannot be depended on to be always on a clean 8b boundary. This was<br /> uncovered on the Cobalt 100 platform.<br /> <br /> SError Interrupt on CPU26, code 0xbe000011 -- SError<br /> CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1<br /> Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION<br /> pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)<br /> pc : cppc_get_perf_caps+0xec/0x410<br /> lr : cppc_get_perf_caps+0xe8/0x410<br /> sp : ffff8000155ab730<br /> x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078<br /> x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff<br /> x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000<br /> x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff<br /> x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008<br /> x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006<br /> x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec<br /> x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028<br /> x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff<br /> x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000<br /> Kernel panic - not syncing: Asynchronous SError Interrupt<br /> CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted<br /> 5.15.2.1-13 #1<br /> Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION<br /> Call trace:<br /> dump_backtrace+0x0/0x1e0<br /> show_stack+0x24/0x30<br /> dump_stack_lvl+0x8c/0xb8<br /> dump_stack+0x18/0x34<br /> panic+0x16c/0x384<br /> add_taint+0x0/0xc0<br /> arm64_serror_panic+0x7c/0x90<br /> arm64_is_fatal_ras_serror+0x34/0xa4<br /> do_serror+0x50/0x6c<br /> el1h_64_error_handler+0x40/0x74<br /> el1h_64_error+0x7c/0x80<br /> cppc_get_perf_caps+0xec/0x410<br /> cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]<br /> cpufreq_online+0x2dc/0xa30<br /> cpufreq_add_dev+0xc0/0xd4<br /> subsys_interface_register+0x134/0x14c<br /> cpufreq_register_driver+0x1b0/0x354<br /> cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]<br /> do_one_initcall+0x50/0x250<br /> do_init_module+0x60/0x27c<br /> load_module+0x2300/0x2570<br /> __do_sys_finit_module+0xa8/0x114<br /> __arm64_sys_finit_module+0x2c/0x3c<br /> invoke_syscall+0x78/0x100<br /> el0_svc_common.constprop.0+0x180/0x1a0<br /> do_el0_svc+0x84/0xa0<br /> el0_svc+0x2c/0xc0<br /> el0t_64_sync_handler+0xa4/0x12c<br /> el0t_64_sync+0x1a4/0x1a8<br /> <br /> Instead, use access_width to determine the size and use the offset and<br /> width to shift and mask the bits to read/write out. Make sure to add a<br /> check for system memory since pcc redefines the access_width to<br /> subspace id.<br /> <br /> If access_width is not set, then fall back to using bit_width.<br /> <br /> [ rjw: Subject and changelog edits, comment adjustments ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix TASK_SIZE on 64-bit NOMMU<br /> <br /> On NOMMU, userspace memory can come from anywhere in physical RAM. The<br /> current definition of TASK_SIZE is wrong if any RAM exists above 4G,<br /> causing spurious failures in the userspace access routines.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma: xilinx_dpdma: Fix locking<br /> <br /> There are several places where either chan-&gt;lock or chan-&gt;vchan.lock was<br /> not held. Add appropriate locking. This fixes lockdep warnings like<br /> <br /> [ 31.077578] ------------[ cut here ]------------<br /> [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0<br /> [ 31.077953] Modules linked in:<br /> [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98<br /> [ 31.078102] Hardware name: xlnx,zynqmp (DT)<br /> [ 31.078169] Workqueue: events_unbound deferred_probe_work_func<br /> [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0<br /> [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0<br /> [ 31.078550] sp : ffffffc083bb2e10<br /> [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168<br /> [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480<br /> [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000<br /> [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000<br /> [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001<br /> [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def<br /> [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516<br /> [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff<br /> [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000<br /> [ 31.080307] Call trace:<br /> [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0<br /> [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120<br /> [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac<br /> [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c<br /> [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684<br /> [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0<br /> [ 31.081139] commit_tail+0x234/0x294<br /> [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210<br /> [ 31.081363] drm_atomic_commit+0x100/0x140<br /> [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384<br /> [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c<br /> [ 31.081725] drm_client_modeset_commit+0x34/0x5c<br /> [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168<br /> [ 31.081899] drm_fb_helper_set_par+0x50/0x70<br /> [ 31.081971] fbcon_init+0x538/0xc48<br /> [ 31.082047] visual_init+0x16c/0x23c<br /> [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634<br /> [ 31.082320] do_take_over_console+0x24c/0x33c<br /> [ 31.082429] do_fbcon_takeover+0xbc/0x1b0<br /> [ 31.082503] fbcon_fb_registered+0x2d0/0x34c<br /> [ 31.082663] register_framebuffer+0x27c/0x38c<br /> [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c<br /> [ 31.082939] drm_fb_helper_initial_config+0x50/0x74<br /> [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108<br /> [ 31.083115] drm_client_register+0xa0/0xf4<br /> [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc<br /> [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0<br /> [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0<br /> [ 31.083616] platform_probe+0x8c/0x13c<br /> [ 31.083713] really_probe+0x258/0x59c<br /> [ 31.083793] __driver_probe_device+0xc4/0x224<br /> [ 31.083878] driver_probe_device+0x70/0x1c0<br /> [ 31.083961] __device_attach_driver+0x108/0x1e0<br /> [ 31.084052] bus_for_each_drv+0x9c/0x100<br /> [ 31.084125] __device_attach+0x100/0x298<br /> [ 31.084207] device_initial_probe+0x14/0x20<br /> [ 31.084292] bus_probe_device+0xd8/0xdc<br /> [ 31.084368] deferred_probe_work_func+0x11c/0x180<br /> [ 31.084451] process_one_work+0x3ac/0x988<br /> [ 31.084643] worker_thread+0x398/0x694<br /> [ 31.084752] kthread+0x1bc/0x1c0<br /> [ 31.084848] ret_from_fork+0x10/0x20<br /> [ 31.084932] irq event stamp: 64549<br /> [ 31.084970] hardirqs last enabled at (64548): [] _raw_spin_unlock_irqrestore+0x80/0x90<br /> [ 31.085157]<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpu: Re-enable CPU mitigations by default for !X86 architectures<br /> <br /> Rename x86&amp;#39;s to CPU_MITIGATIONS, define it in generic code, and force it<br /> on for all architectures exception x86. A recent commit to turn<br /> mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta<br /> missed that "cpu_mitigations" is completely generic, whereas<br /> SPECULATION_MITIGATIONS is x86-specific.<br /> <br /> Rename x86&amp;#39;s SPECULATIVE_MITIGATIONS instead of keeping both and have it<br /> select CPU_MITIGATIONS, as having two configs for the same thing is<br /> unnecessary and confusing. This will also allow x86 to use the knob to<br /> manage mitigations that aren&amp;#39;t strictly related to speculative<br /> execution.<br /> <br /> Use another Kconfig to communicate to common code that CPU_MITIGATIONS<br /> is already defined instead of having x86&amp;#39;s menu depend on the common<br /> CPU_MITIGATIONS. This allows keeping a single point of contact for all<br /> of x86&amp;#39;s mitigations, and it&amp;#39;s not clear that other architectures *want*<br /> to allow disabling mitigations at compile-time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up<br /> <br /> The flag I2C_HID_READ_PENDING is used to serialize I2C operations.<br /> However, this is not necessary, because I2C core already has its own<br /> locking for that.<br /> <br /> More importantly, this flag can cause a lock-up: if the flag is set in<br /> i2c_hid_xfer() and an interrupt happens, the interrupt handler<br /> (i2c_hid_irq) will check this flag and return immediately without doing<br /> anything, then the interrupt handler will be invoked again in an<br /> infinite loop.<br /> <br /> Since interrupt handler is an RT task, it takes over the CPU and the<br /> flag-clearing task never gets scheduled, thus we have a lock-up.<br /> <br /> Delete this unnecessary flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init()<br /> <br /> If ulp = kzalloc() fails, the allocated edev will leak because it is<br /> not properly assigned and the cleanup path will not be able to free it.<br /> Fix it by assigning it properly immediately after allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: Fix transmit scheduler resource leak<br /> <br /> Inorder to support shaping and scheduling, Upon class creation<br /> Netdev driver allocates trasmit schedulers.<br /> <br /> The previous patch which added support for Round robin scheduling has<br /> a bug due to which driver is not freeing transmit schedulers post<br /> class deletion.<br /> <br /> This patch fixes the same.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/chrome: cros_ec_uart: properly fix race condition<br /> <br /> The cros_ec_uart_probe() function calls devm_serdev_device_open() before<br /> it calls serdev_device_set_client_ops(). This can trigger a NULL pointer<br /> dereference:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> Call Trace:<br /> <br /> ...<br /> ? ttyport_receive_buf<br /> <br /> A simplified version of crashing code is as follows:<br /> <br /> static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl,<br /> const u8 *data,<br /> size_t count)<br /> {<br /> struct serdev_device *serdev = ctrl-&gt;serdev;<br /> <br /> if (!serdev || !serdev-&gt;ops-&gt;receive_buf) // CRASH!<br /> return 0;<br /> <br /> return serdev-&gt;ops-&gt;receive_buf(serdev, data, count);<br /> }<br /> <br /> It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev-&gt;ops<br /> will also exist. This conflicts with the existing cros_ec_uart_probe()<br /> logic, as it first calls devm_serdev_device_open() (which sets<br /> SERPORT_ACTIVE), and only later sets serdev-&gt;ops via<br /> serdev_device_set_client_ops().<br /> <br /> Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race<br /> condition") attempted to fix a similar race condition, but while doing<br /> so, made the window of error for this race condition to happen much<br /> wider.<br /> <br /> Attempt to fix the race condition again, making sure we fully setup<br /> before calling devm_serdev_device_open().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> raid1: fix use-after-free for original bio in raid1_write_request()<br /> <br /> r1_bio-&gt;bios[] is used to record new bios that will be issued to<br /> underlying disks, however, in raid1_write_request(), r1_bio-&gt;bios[]<br /> will set to the original bio temporarily. Meanwhile, if blocked rdev<br /> is set, free_r1bio() will be called causing that all r1_bio-&gt;bios[]<br /> to be freed:<br /> <br /> raid1_write_request()<br /> r1_bio = alloc_r1bio(mddev, bio); -&gt; r1_bio-&gt;bios[] is NULL<br /> for (i = 0; i for each rdev in conf<br /> // first rdev is normal<br /> r1_bio-&gt;bios[0] = bio; -&gt; set to original bio<br /> // second rdev is blocked<br /> if (test_bit(Blocked, &amp;rdev-&gt;flags))<br /> break<br /> <br /> if (blocked_rdev)<br /> free_r1bio()<br /> put_all_bios()<br /> bio_put(r1_bio-&gt;bios[0]) -&gt; original bio is freed<br /> <br /> Test scripts:<br /> <br /> mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean<br /> fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \<br /> -iodepth=128 -name=test -direct=1<br /> echo blocked &gt; /sys/block/md0/md/rd2/state<br /> <br /> Test result:<br /> <br /> BUG bio-264 (Not tainted): Object already free<br /> -----------------------------------------------------------------------------<br /> <br /> Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869<br /> kmem_cache_alloc+0x324/0x480<br /> mempool_alloc_slab+0x24/0x50<br /> mempool_alloc+0x6e/0x220<br /> bio_alloc_bioset+0x1af/0x4d0<br /> blkdev_direct_IO+0x164/0x8a0<br /> blkdev_write_iter+0x309/0x440<br /> aio_write+0x139/0x2f0<br /> io_submit_one+0x5ca/0xb70<br /> __do_sys_io_submit+0x86/0x270<br /> __x64_sys_io_submit+0x22/0x30<br /> do_syscall_64+0xb1/0x210<br /> entry_SYSCALL_64_after_hwframe+0x6c/0x74<br /> Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869<br /> kmem_cache_free+0x28c/0x550<br /> mempool_free_slab+0x1f/0x30<br /> mempool_free+0x40/0x100<br /> bio_free+0x59/0x80<br /> bio_put+0xf0/0x220<br /> free_r1bio+0x74/0xb0<br /> raid1_make_request+0xadf/0x1150<br /> md_handle_request+0xc7/0x3b0<br /> md_submit_bio+0x76/0x130<br /> __submit_bio+0xd8/0x1d0<br /> submit_bio_noacct_nocheck+0x1eb/0x5c0<br /> submit_bio_noacct+0x169/0xd40<br /> submit_bio+0xee/0x1d0<br /> blkdev_direct_IO+0x322/0x8a0<br /> blkdev_write_iter+0x309/0x440<br /> aio_write+0x139/0x2f0<br /> <br /> Since that bios for underlying disks are not allocated yet, fix this<br /> problem by using mempool_free() directly to free the r1_bio.