Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: Fix null pointer dereference in remove if xHC has only one roothub<br /> <br /> The remove path in xhci platform driver tries to remove and put both main<br /> and shared hcds even if only a main hcd exists (one roothub)<br /> <br /> This causes a null pointer dereference in reboot for those controllers.<br /> <br /> Check that the shared_hcd exists before trying to remove it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/ttm: fix CCS handling<br /> <br /> Crucible + recent Mesa seems to sometimes hit:<br /> <br /> GEM_BUG_ON(num_ccs_blks &gt; NUM_CCS_BLKS_PER_XFER)<br /> <br /> And it looks like we can also trigger this with gem_lmem_swapping, if we<br /> modify the test to use slightly larger object sizes.<br /> <br /> Looking closer it looks like we have the following issues in<br /> migrate_copy():<br /> <br /> - We are using plain integer in various places, which we can easily<br /> overflow with a large object.<br /> <br /> - We pass the entire object size (when the src is lmem) into<br /> emit_pte() and then try to copy it, which doesn&amp;#39;t work, since we<br /> only have a few fixed sized windows in which to map the pages and<br /> perform the copy. With an object &gt; 8M we therefore aren&amp;#39;t properly<br /> copying the pages. And then with an object &gt; 64M we trigger the<br /> GEM_BUG_ON(num_ccs_blks &gt; NUM_CCS_BLKS_PER_XFER).<br /> <br /> So it looks like our copy handling for any object &gt; 8M (which is our<br /> CHUNK_SZ) is currently broken on DG2.<br /> <br /> Testcase: igt@gem_lmem_swapping<br /> (cherry picked from commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level<br /> <br /> Though acpi_find_last_cache_level() always returned signed value and the<br /> document states it will return any errors caused by lack of a PPTT table,<br /> it never returned negative values before.<br /> <br /> Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")<br /> however changed it by returning -ENOENT if no PPTT was found. The value<br /> returned from acpi_find_last_cache_level() is then assigned to unsigned<br /> fw_level.<br /> <br /> It will result in the number of cache leaves calculated incorrectly as<br /> a huge value which will then cause the following warning from __alloc_pages<br /> as the order would be great than MAX_ORDER because of incorrect and huge<br /> cache leaves value.<br /> <br /> | WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:5407 __alloc_pages+0x74/0x314<br /> | Modules linked in:<br /> | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73<br /> | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : __alloc_pages+0x74/0x314<br /> | lr : alloc_pages+0xe8/0x318<br /> | Call trace:<br /> | __alloc_pages+0x74/0x314<br /> | alloc_pages+0xe8/0x318<br /> | kmalloc_order_trace+0x68/0x1dc<br /> | __kmalloc+0x240/0x338<br /> | detect_cache_attributes+0xe0/0x56c<br /> | update_siblings_masks+0x38/0x284<br /> | store_cpu_topology+0x78/0x84<br /> | smp_prepare_cpus+0x48/0x134<br /> | kernel_init_freeable+0xc4/0x14c<br /> | kernel_init+0x2c/0x1b4<br /> | ret_from_fork+0x10/0x20<br /> <br /> Fix the same by changing fw_level to be signed integer and return the<br /> error from init_cache_level() early in case of error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: add missing -&gt;fini_xxxx interfaces for some SMU13 asics<br /> <br /> Without these, potential memory leak may be induced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: add missing -&gt;fini_microcode interface for Sienna Cichlid<br /> <br /> To avoid any potential memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix memory corruption on open<br /> <br /> The probe session-duplication overflow check incremented the session<br /> count also when there were no more available sessions so that memory<br /> beyond the fixed-size slab-allocated session array could be corrupted in<br /> fastrpc_session_alloc() on open().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware_loader: Fix use-after-free during unregister<br /> <br /> In the following code within firmware_upload_unregister(), the call to<br /> device_unregister() could result in the dev_release function freeing the<br /> fw_upload_priv structure before it is dereferenced for the call to<br /> module_put(). This bug was found by the kernel test robot using<br /> CONFIG_KASAN while running the firmware selftests.<br /> <br /> device_unregister(&amp;fw_sysfs-&gt;dev);<br /> module_put(fw_upload_priv-&gt;module);<br /> <br /> The problem is fixed by copying fw_upload_priv-&gt;module to a local variable<br /> for use when calling device_unregister().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix memory corruption on probe<br /> <br /> Add the missing sanity check on the probed-session count to avoid<br /> corrupting memory beyond the fixed-size slab-allocated session array<br /> when there are more than FASTRPC_MAX_SESSIONS sessions defined in the<br /> devicetree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: cm3605: Fix an error handling path in cm3605_probe()<br /> <br /> The commit in Fixes also introduced a new error handling path which should<br /> goto the existing error handling path.<br /> Otherwise some resources leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag<br /> <br /> syzbot is reporting hung task at __input_unregister_device() [1], for<br /> iforce_close() waiting at wait_event_interruptible() with dev-&gt;mutex held<br /> is blocking input_disconnect_device() from __input_unregister_device().<br /> <br /> It seems that the cause is simply that commit c2b27ef672992a20 ("Input:<br /> iforce - wait for command completion when closing the device") forgot to<br /> call wake_up() after clear_bit().<br /> <br /> Fix this problem by introducing a helper that calls clear_bit() followed<br /> by wake_up_all().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/rtas: Fix RTAS MSR[HV] handling for Cell<br /> <br /> The semi-recent changes to MSR handling when entering RTAS (firmware)<br /> cause crashes on IBM Cell machines. An example trace:<br /> <br /> kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)<br /> BUG: Unable to handle kernel instruction fetch<br /> Faulting instruction address: 0x2fff01a8<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell<br /> Modules linked in:<br /> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.0.0-rc2-00433-gede0a8d3307a #207<br /> NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 0000000000000000<br /> REGS: c0000000015236b0 TRAP: 0400 Tainted: G W (6.0.0-rc2-00433-gede0a8d3307a)<br /> MSR: 0000000008001002 CR: 00000000 XER: 20000000<br /> ...<br /> NIP 0x2fff01a8<br /> LR 0x32608<br /> Call Trace:<br /> 0xc00000000143c5f8 (unreliable)<br /> .rtas_call+0x224/0x320<br /> .rtas_get_boot_time+0x70/0x150<br /> .read_persistent_clock64+0x114/0x140<br /> .read_persistent_wall_and_boot_offset+0x24/0x80<br /> .timekeeping_init+0x40/0x29c<br /> .start_kernel+0x674/0x8f0<br /> start_here_common+0x1c/0x50<br /> <br /> Unlike PAPR platforms where RTAS is only used in guests, on the IBM Cell<br /> machines Linux runs with MSR[HV] set but also uses RTAS, provided by<br /> SLOF.<br /> <br /> Fix it by copying the MSR[HV] bit from the MSR value we&amp;#39;ve just read<br /> using mfmsr into the value used for RTAS.<br /> <br /> It seems like we could also fix it using an #ifdef CELL to set MSR[HV],<br /> but that doesn&amp;#39;t work because it&amp;#39;s possible to build a single kernel<br /> image that runs on both Cell native and pseries.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8712: fix use after free bugs<br /> <br /> _Read/Write_MACREG callbacks are NULL so the read/write_macreg_hdl()<br /> functions don&amp;#39;t do anything except free the "pcmd" pointer. It<br /> results in a use after free. Delete them.