Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix error path in multi-packet WQE transmit<br /> <br /> Remove the erroneous unmap in case no DMA mapping was established<br /> <br /> The multi-packet WQE transmit code attempts to obtain a DMA mapping for<br /> the skb. This could fail, e.g. under memory pressure, when the IOMMU<br /> driver just can&amp;#39;t allocate more memory for page tables. While the code<br /> tries to handle this in the path below the err_unmap label it erroneously<br /> unmaps one entry from the sq&amp;#39;s FIFO list of active mappings. Since the<br /> current map attempt failed this unmap is removing some random DMA mapping<br /> that might still be required. If the PCI function now presents that IOVA,<br /> the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI<br /> function in error state.<br /> <br /> The erroneous behavior was seen in a stress-test environment that created<br /> memory pressure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> static_call: Handle module init failure correctly in static_call_del_module()<br /> <br /> Module insertion invokes static_call_add_module() to initialize the static<br /> calls in a module. static_call_add_module() invokes __static_call_init(),<br /> which allocates a struct static_call_mod to either encapsulate the built-in<br /> static call sites of the associated key into it so further modules can be<br /> added or to append the module to the module chain.<br /> <br /> If that allocation fails the function returns with an error code and the<br /> module core invokes static_call_del_module() to clean up eventually added<br /> static_call_mod entries.<br /> <br /> This works correctly, when all keys used by the module were converted over<br /> to a module chain before the failure. If not then static_call_del_module()<br /> causes a #GP as it blindly assumes that key::mods points to a valid struct<br /> static_call_mod.<br /> <br /> The problem is that key::mods is not a individual struct member of struct<br /> static_call_key, it&amp;#39;s part of a union to save space:<br /> <br /> union {<br /> /* bit 0: 0 = mods, 1 = sites */<br /> unsigned long type;<br /> struct static_call_mod *mods;<br /> struct static_call_site *sites;<br /> };<br /> <br /> key::sites is a pointer to the list of built-in usage sites of the static<br /> call. The type of the pointer is differentiated by bit 0. A mods pointer<br /> has the bit clear, the sites pointer has the bit set.<br /> <br /> As static_call_del_module() blidly assumes that the pointer is a valid<br /> static_call_mod type, it fails to check for this failure case and<br /> dereferences the pointer to the list of built-in call sites, which is<br /> obviously bogus.<br /> <br /> Cure it by checking whether the key has a sites or a mods pointer.<br /> <br /> If it&amp;#39;s a sites pointer then the key is not to be touched. As the sites are<br /> walked in the same order as in __static_call_init() the site walk can be<br /> terminated because all subsequent sites have not been touched by the init<br /> code due to the error exit.<br /> <br /> If it was converted before the allocation fail, then the inner loop which<br /> searches for a module match will find nothing.<br /> <br /> A fail in the second allocation in __static_call_init() is harmless and<br /> does not require special treatment. The first allocation succeeded and<br /> converted the key to a module chain. That first entry has mod::mod == NULL<br /> and mod::next == NULL, so the inner loop of static_call_del_module() will<br /> neither find a module match nor a module chain. The next site in the walk<br /> was either already converted, but can&amp;#39;t match the module, or it will exit<br /> the outer loop because it has a static_call_site pointer and not a<br /> static_call_mod pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpftool: Fix undefined behavior in qsort(NULL, 0, ...)<br /> <br /> When netfilter has no entry to display, qsort is called with<br /> qsort(NULL, 0, ...). This results in undefined behavior, as UBSan<br /> reports:<br /> <br /> net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null<br /> <br /> Although the C standard does not explicitly state whether calling qsort<br /> with a NULL pointer when the size is 0 constitutes undefined behavior,<br /> Section 7.1.4 of the C standard (Use of library functions) mentions:<br /> <br /> "Each of the following statements applies unless explicitly stated<br /> otherwise in the detailed descriptions that follow: If an argument to a<br /> function has an invalid value (such as a value outside the domain of<br /> the function, or a pointer outside the address space of the program, or<br /> a null pointer, or a pointer to non-modifiable storage when the<br /> corresponding parameter is not const-qualified) or a type (after<br /> promotion) not expected by a function with variable number of<br /> arguments, the behavior is undefined."<br /> <br /> To avoid this, add an early return when nf_link_info is NULL to prevent<br /> calling qsort with a NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: add refcnt to ksmbd_conn struct<br /> <br /> When sending an oplock break request, opinfo-&gt;conn is used,<br /> But freed -&gt;conn can be used on multichannel.<br /> This patch add a reference count to the ksmbd_conn struct<br /> so that it can be freed when it is no longer used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/hdcp: Check GSC structure validity<br /> <br /> Sometimes xe_gsc is not initialized when checked at HDCP capability<br /> check. Add gsc structure check to avoid null pointer error.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix the setting of the server responding flag<br /> <br /> In afs_wait_for_operation(), we set transcribe the call responded flag to<br /> the server record that we used after doing the fileserver iteration loop -<br /> but it&amp;#39;s possible to exit the loop having had a response from the server<br /> that we&amp;#39;ve discarded (e.g. it returned an abort or we started receiving<br /> data, but the call didn&amp;#39;t complete).<br /> <br /> This means that op-&gt;server might be NULL, but we don&amp;#39;t check that before<br /> attempting to set the server flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix integer overflow in BLKSECDISCARD<br /> <br /> I independently rediscovered<br /> <br /> commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155<br /> block: fix overflow in blk_ioctl_discard()<br /> <br /> but for secure erase.<br /> <br /> Same problem:<br /> <br /> uint64_t r[2] = {512, 18446744073709551104ULL};<br /> ioctl(fd, BLKSECDISCARD, r);<br /> <br /> will enter near infinite loop inside blkdev_issue_secure_erase():<br /> <br /> a.out: attempt to access beyond end of device<br /> loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048<br /> bio_check_eod: 3286214 callbacks suppressed

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix buffer overflow when parsing NFS reparse points<br /> <br /> ReparseDataLength is sum of the InodeType size and DataBuffer size.<br /> So to get DataBuffer size it is needed to subtract InodeType&amp;#39;s size from<br /> ReparseDataLength.<br /> <br /> Function cifs_strndup_from_utf16() is currentlly accessing buf-&gt;DataBuffer<br /> at position after the end of the buffer because it does not subtract<br /> InodeType size from the length. Fix this problem and correctly subtract<br /> variable len.<br /> <br /> Member InodeType is present only when reparse buffer is large enough. Check<br /> for ReparseDataLength before accessing InodeType to prevent another invalid<br /> memory access.<br /> <br /> Major and minor rdev values are present also only when reparse buffer is<br /> large enough. Check for reparse buffer size before calling reparse_mkdev().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix double free issue during amdgpu module unload<br /> <br /> Flexible endpoints use DIGs from available inflexible endpoints,<br /> so only the encoders of inflexible links need to be freed.<br /> Otherwise, a double free issue may occur when unloading the<br /> amdgpu module.<br /> <br /> [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0<br /> [ 279.190577] Call Trace:<br /> [ 279.190580] <br /> [ 279.190582] ? show_regs+0x69/0x80<br /> [ 279.190590] ? die+0x3b/0x90<br /> [ 279.190595] ? do_trap+0xc8/0xe0<br /> [ 279.190601] ? do_error_trap+0x73/0xa0<br /> [ 279.190605] ? __slab_free+0x152/0x2f0<br /> [ 279.190609] ? exc_invalid_op+0x56/0x70<br /> [ 279.190616] ? __slab_free+0x152/0x2f0<br /> [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30<br /> [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]<br /> [ 279.191096] ? __slab_free+0x152/0x2f0<br /> [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]<br /> [ 279.191469] kfree+0x260/0x2b0<br /> [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]<br /> [ 279.191821] link_destroy+0xd7/0x130 [amdgpu]<br /> [ 279.192248] dc_destruct+0x90/0x270 [amdgpu]<br /> [ 279.192666] dc_destroy+0x19/0x40 [amdgpu]<br /> [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu]<br /> [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu]<br /> [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu]<br /> [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu]<br /> [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu]<br /> [ 279.194632] pci_device_remove+0x3a/0xa0<br /> [ 279.194638] device_remove+0x40/0x70<br /> [ 279.194642] device_release_driver_internal+0x1ad/0x210<br /> [ 279.194647] driver_detach+0x4e/0xa0<br /> [ 279.194650] bus_remove_driver+0x6f/0xf0<br /> [ 279.194653] driver_unregister+0x33/0x60<br /> [ 279.194657] pci_unregister_driver+0x44/0x90<br /> [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu]<br /> [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0<br /> [ 279.194946] __x64_sys_delete_module+0x16/0x20<br /> [ 279.194950] do_syscall_64+0x58/0x120<br /> [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 279.194980]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors<br /> <br /> x86_android_tablet_remove() frees the pdevs[] array, so it should not<br /> be used after calling x86_android_tablet_remove().<br /> <br /> When platform_device_register() fails, store the pdevs[x] PTR_ERR() value<br /> into the local ret variable before calling x86_android_tablet_remove()<br /> to avoid using pdevs[] after it has been freed.