Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Do not use WQ_MEM_RECLAIM flag for workqueue<br /> <br /> Issue reported by customer during SRIOV testing, call trace:<br /> When both i40e and the i40iw driver are loaded, a warning<br /> in check_flush_dependency is being triggered. This seems<br /> to be because of the i40e driver workqueue is allocated with<br /> the WQ_MEM_RECLAIM flag, and the i40iw one is not.<br /> <br /> Similar error was encountered on ice too and it was fixed by<br /> removing the flag. Do the same for i40e too.<br /> <br /> [Feb 9 09:08] ------------[ cut here ]------------<br /> [ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is<br /> flushing !WQ_MEM_RECLAIM infiniband:0x0<br /> [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966<br /> check_flush_dependency+0x10b/0x120<br /> [ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq<br /> snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4<br /> nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr<br /> rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma<br /> intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif<br /> isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal<br /> intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core<br /> iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore<br /> ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich<br /> intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad<br /> xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe<br /> drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel<br /> libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror<br /> dm_region_hash dm_log dm_mod fuse<br /> [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not<br /> tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1<br /> [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS<br /> SE5C620.86B.02.01.0013.121520200651 12/15/2020<br /> [ +0.000001] Workqueue: i40e i40e_service_task [i40e]<br /> [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120<br /> [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48<br /> 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd<br /> ff 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90<br /> [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282<br /> [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:<br /> 0000000000000027<br /> [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:<br /> ffff94d47f620bc0<br /> [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:<br /> 00000000ffff7fff<br /> [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:<br /> ffff94c5451ea180<br /> [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:<br /> ffff94c5f1330ab0<br /> [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)<br /> knlGS:0000000000000000<br /> [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:<br /> 00000000007706f0<br /> [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [ +0.000001] PKRU: 55555554<br /> [ +0.000001] Call Trace:<br /> [ +0.000001] <br /> [ +0.000002] ? __warn+0x80/0x130<br /> [ +0.000003] ? check_flush_dependency+0x10b/0x120<br /> [ +0.000002] ? report_bug+0x195/0x1a0<br /> [ +0.000005] ? handle_bug+0x3c/0x70<br /> [ +0.000003] ? exc_invalid_op+0x14/0x70<br /> [ +0.000002] ? asm_exc_invalid_op+0x16/0x20<br /> [ +0.000006] ? check_flush_dependency+0x10b/0x120<br /> [ +0.000002] ? check_flush_dependency+0x10b/0x120<br /> [ +0.000002] __flush_workqueue+0x126/0x3f0<br /> [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]<br /> [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]<br /> [ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]<br /> [ +0.000020] i40iw_close+0x4b/0x90 [irdma]<br /> [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]<br /> [ +0.000035] i40e_service_task+0x126/0x190 [i40e]<br /> [ +0.000024] process_one_work+0x174/0x340<br /> [ +0.000003] worker_th<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix loading 64-bit NOMMU kernels past the start of RAM<br /> <br /> commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear<br /> mapping") added logic to allow using RAM below the kernel load address.<br /> However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the<br /> kernel load address. Since that range of memory corresponds to PFNs<br /> below ARCH_PFN_OFFSET, mm initialization runs off the beginning of<br /> mem_map and corrupts adjacent kernel memory. Fix this by restoring the<br /> previous behavior for NOMMU kernels.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix oops during rmmod on single-CPU platforms<br /> <br /> During the removal of the idxd driver, registered offline callback is<br /> invoked as part of the clean up process. However, on systems with only<br /> one CPU online, no valid target is available to migrate the<br /> perf context, resulting in a kernel oops:<br /> <br /> BUG: unable to handle page fault for address: 000000000002a2b8<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 1470e1067 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57<br /> Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023<br /> RIP: 0010:mutex_lock+0x2e/0x50<br /> ...<br /> Call Trace:<br /> <br /> __die+0x24/0x70<br /> page_fault_oops+0x82/0x160<br /> do_user_addr_fault+0x65/0x6b0<br /> __pfx___rdmsr_safe_on_cpu+0x10/0x10<br /> exc_page_fault+0x7d/0x170<br /> asm_exc_page_fault+0x26/0x30<br /> mutex_lock+0x2e/0x50<br /> mutex_lock+0x1e/0x50<br /> perf_pmu_migrate_context+0x87/0x1f0<br /> perf_event_cpu_offline+0x76/0x90 [idxd]<br /> cpuhp_invoke_callback+0xa2/0x4f0<br /> __pfx_perf_event_cpu_offline+0x10/0x10 [idxd]<br /> cpuhp_thread_fun+0x98/0x150<br /> smpboot_thread_fn+0x27/0x260<br /> smpboot_thread_fn+0x1af/0x260<br /> __pfx_smpboot_thread_fn+0x10/0x10<br /> kthread+0x103/0x140<br /> __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x50<br /> __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> Fix the issue by preventing the migration of the perf context to an<br /> invalid target.

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 /> dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue<br /> <br /> drain_workqueue() cannot be called safely in a spinlocked context due to<br /> possible task rescheduling. In the multi-task scenario, calling<br /> queue_work() while drain_workqueue() will lead to a Call Trace as<br /> pushing a work on a draining workqueue is not permitted in spinlocked<br /> context.<br /> Call Trace:<br /> <br /> ? __warn+0x7d/0x140<br /> ? __queue_work+0x2b2/0x440<br /> ? report_bug+0x1f8/0x200<br /> ? handle_bug+0x3c/0x70<br /> ? exc_invalid_op+0x18/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? __queue_work+0x2b2/0x440<br /> queue_work_on+0x28/0x30<br /> idxd_misc_thread+0x303/0x5a0 [idxd]<br /> ? __schedule+0x369/0xb40<br /> ? __pfx_irq_thread_fn+0x10/0x10<br /> ? irq_thread+0xbc/0x1b0<br /> irq_thread_fn+0x21/0x70<br /> irq_thread+0x102/0x1b0<br /> ? preempt_count_add+0x74/0xa0<br /> ? __pfx_irq_thread_dtor+0x10/0x10<br /> ? __pfx_irq_thread+0x10/0x10<br /> kthread+0x103/0x140<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The current implementation uses a spinlock to protect event log workqueue<br /> and will lead to the Call Trace due to potential task rescheduling.<br /> <br /> To address the locking issue, convert the spinlock to mutex, allowing<br /> the drain_workqueue() to be called in a safe mutex-locked context.<br /> <br /> This change ensures proper synchronization when accessing the event log<br /> workqueue, preventing potential Call Trace and improving the overall<br /> robustness of the code.

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 /> 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 /> 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 /> 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.