Vulnerabilities

Rejected reason: Not used

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()<br /> <br /> If speed_hz

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: gpib: Fix cb7210 pcmcia Oops<br /> <br /> The pcmcia_driver struct was still only using the old .name<br /> initialization in the drv field. This led to a NULL pointer<br /> deref Oops in strcmp called from pcmcia_register_driver.<br /> <br /> Initialize the pcmcia_driver struct name field.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> objtool, nvmet: Fix out-of-bounds stack access in nvmet_ctrl_state_show()<br /> <br /> The csts_state_names[] array only has six sparse entries, but the<br /> iteration code in nvmet_ctrl_state_show() iterates seven, resulting in a<br /> potential out-of-bounds stack read. Fix that.<br /> <br /> Fixes the following warning with an UBSAN kernel:<br /> <br /> vmlinux.o: warning: objtool: .text.nvmet_ctrl_state_show: unexpected end of section

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: Add check for array bounds in veml6075_read_int_time_ms<br /> <br /> The array contains only 5 elements, but the index calculated by<br /> veml6075_read_int_time_index can range from 0 to 7,<br /> which could lead to out-of-bounds access. The check prevents this issue.<br /> <br /> Coverity Issue<br /> CID 1574309: (#1 of 1): Out-of-bounds read (OVERRUN)<br /> overrun-local: Overrunning array veml6075_it_ms of 5 4-byte<br /> elements at element index 7 (byte offset 31) using<br /> index int_index (which evaluates to 7)<br /> <br /> This is hardening against potentially broken hardware. Good to have<br /> but not necessary to backport.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mce: use is_copy_from_user() to determine copy-from-user context<br /> <br /> Patch series "mm/hwpoison: Fix regressions in memory failure handling",<br /> v4.<br /> <br /> ## 1. What am I trying to do:<br /> <br /> This patchset resolves two critical regressions related to memory failure<br /> handling that have appeared in the upstream kernel since version 5.17, as<br /> compared to 5.10 LTS.<br /> <br /> - copyin case: poison found in user page while kernel copying from user space<br /> - instr case: poison found while instruction fetching in user space<br /> <br /> ## 2. What is the expected outcome and why<br /> <br /> - For copyin case:<br /> <br /> Kernel can recover from poison found where kernel is doing get_user() or<br /> copy_from_user() if those places get an error return and the kernel return<br /> -EFAULT to the process instead of crashing. More specifily, MCE handler<br /> checks the fixup handler type to decide whether an in kernel #MC can be<br /> recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code<br /> specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.<br /> <br /> - For instr case:<br /> <br /> If a poison found while instruction fetching in user space, full recovery<br /> is possible. User process takes #PF, Linux allocates a new page and fills<br /> by reading from storage.<br /> <br /> <br /> ## 3. What actually happens and why<br /> <br /> - For copyin case: kernel panic since v5.17<br /> <br /> Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new<br /> extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the<br /> extable fixup type for copy-from-user operations, changing it from<br /> EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS<br /> handling when posion found in get_user() or copy_from_user().<br /> <br /> - For instr case: user process is killed by a SIGBUS signal due to #CMCI<br /> and #MCE race<br /> <br /> When an uncorrected memory error is consumed there is a race between the<br /> CMCI from the memory controller reporting an uncorrected error with a UCNA<br /> signature, and the core reporting and SRAR signature machine check when<br /> the data is about to be consumed.<br /> <br /> ### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]<br /> <br /> Prior to Icelake memory controllers reported patrol scrub events that<br /> detected a previously unseen uncorrected error in memory by signaling a<br /> broadcast machine check with an SRAO (Software Recoverable Action<br /> Optional) signature in the machine check bank. This was overkill because<br /> it&amp;#39;s not an urgent problem that no core is on the verge of consuming that<br /> bad data. It&amp;#39;s also found that multi SRAO UCE may cause nested MCE<br /> interrupts and finally become an IERR.<br /> <br /> Hence, Intel downgrades the machine check bank signature of patrol scrub<br /> from SRAO to UCNA (Uncorrected, No Action required), and signal changed to<br /> #CMCI. Just to add to the confusion, Linux does take an action (in<br /> uc_decode_notifier()) to try to offline the page despite the UC*NA*<br /> signature name.<br /> <br /> ### Background: why #CMCI and #MCE race when poison is consuming in<br /> Intel platform [1]<br /> <br /> Having decided that CMCI/UCNA is the best action for patrol scrub errors,<br /> the memory controller uses it for reads too. But the memory controller is<br /> executing asynchronously from the core, and can&amp;#39;t tell the difference<br /> between a "real" read and a speculative read. So it will do CMCI/UCNA if<br /> an error is found in any read.<br /> <br /> Thus:<br /> <br /> 1) Core is clever and thinks address A is needed soon, issues a<br /> speculative read.<br /> <br /> 2) Core finds it is going to use address A soon after sending the read<br /> request<br /> <br /> 3) The CMCI from the memory controller is in a race with MCE from the<br /> core that will soon try to retire the load from address A.<br /> <br /> Quite often (because speculation has got better) the CMCI from the memory<br /> controller is delivered before the core is committed to the instruction<br /> reading address A, so the interrupt is taken, and Linux offlines the page<br /> (marking it as poison).<br /> <br /> <br /> ## Why user process is killed for instr case<br /> <br /> Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported<br /> "not<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: wait barrier before returning discard request with REQ_NOWAIT<br /> <br /> raid10_handle_discard should wait barrier before returning a discard bio<br /> which has REQ_NOWAIT. And there is no need to print warning calltrace<br /> if a discard bio has REQ_NOWAIT flag. Quality engineer usually checks<br /> dmesg and reports error if dmesg has warning/error calltrace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: samsung: Fix UBSAN panic in samsung_clk_init()<br /> <br /> With UBSAN_ARRAY_BOUNDS=y, I&amp;#39;m hitting the below panic due to<br /> dereferencing `ctx-&gt;clk_data.hws` before setting<br /> `ctx-&gt;clk_data.num = nr_clks`. Move that up to fix the crash.<br /> <br /> UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP<br /> <br /> Call trace:<br /> samsung_clk_init+0x110/0x124 (P)<br /> samsung_clk_init+0x48/0x124 (L)<br /> samsung_cmu_register_one+0x3c/0xa0<br /> exynos_arm64_register_cmu+0x54/0x64<br /> __gs101_cmu_top_of_clk_init_declare+0x28/0x60<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix slab-out-of-bounds read in ea_get()<br /> <br /> During the "size_check" label in ea_get(), the code checks if the extended<br /> attribute list (xattr) size matches ea_size. If not, it logs<br /> "ea_get: invalid extended attribute" and calls print_hex_dump().<br /> <br /> Here, EALIST_SIZE(ea_buf-&gt;xattr) returns 4110417968, which exceeds<br /> INT_MAX (2,147,483,647). Then ea_size is clamped:<br /> <br /> int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf-&gt;xattr));<br /> <br /> Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper<br /> limit is treated as an int, causing an overflow above 2^31 - 1. This leads<br /> "size" to wrap around and become negative (-184549328).<br /> <br /> The "size" is then passed to print_hex_dump() (called "len" in<br /> print_hex_dump()), it is passed as type size_t (an unsigned<br /> type), this is then stored inside a variable called<br /> "int remaining", which is then assigned to "int linelen" which<br /> is then passed to hex_dump_to_buffer(). In print_hex_dump()<br /> the for loop, iterates through 0 to len-1, where len is<br /> 18446744073525002176, calling hex_dump_to_buffer()<br /> on each iteration:<br /> <br /> for (i = 0; i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: simple-card-utils: Don&amp;#39;t use __free(device_node) at graph_util_parse_dai()<br /> <br /> commit 419d1918105e ("ASoC: simple-card-utils: use __free(device_node) for<br /> device node") uses __free(device_node) for dlc-&gt;of_node, but we need to<br /> keep it while driver is in use.<br /> <br /> Don&amp;#39;t use __free(device_node) in graph_util_parse_dai().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors<br /> <br /> Commit<br /> <br /> 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid")<br /> <br /> added logic that causes resctrl to search for the CLOSID with the fewest dirty<br /> cache lines when creating a new control group, if requested by the arch code.<br /> This depends on the values read from the llc_occupancy counters. The logic is<br /> applicable to architectures where the CLOSID effectively forms part of the<br /> monitoring identifier and so do not allow complete freedom to choose an unused<br /> monitoring identifier for a given CLOSID.<br /> <br /> This support missed that some platforms may not have these counters. This<br /> causes a NULL pointer dereference when creating a new control group as the<br /> array was not allocated by dom_data_init().<br /> <br /> As this feature isn&amp;#39;t necessary on platforms that don&amp;#39;t have cache occupancy<br /> monitors, add this to the check that occurs when a new control group is<br /> allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: fsl-edma: free irq correctly in remove path<br /> <br /> Add fsl_edma-&gt;txirq/errirq check to avoid below warning because no<br /> errirq at i.MX9 platform. Otherwise there will be kernel dump:<br /> WARNING: CPU: 0 PID: 11 at kernel/irq/devres.c:144 devm_free_irq+0x74/0x80<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/u8:0 Not tainted 6.12.0-rc7#18<br /> Hardware name: NXP i.MX93 11X11 EVK board (DT)<br /> Workqueue: events_unbound deferred_probe_work_func<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : devm_free_irq+0x74/0x80<br /> lr : devm_free_irq+0x48/0x80<br /> Call trace:<br /> devm_free_irq+0x74/0x80 (P)<br /> devm_free_irq+0x48/0x80 (L)<br /> fsl_edma_remove+0xc4/0xc8<br /> platform_remove+0x28/0x44<br /> device_remove+0x4c/0x80