Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer<br /> <br /> Pass pointer reference to amdgpu_bo_unref to clear the correct pointer,<br /> otherwise amdgpu_bo_unref clear the local variable, the original pointer<br /> not set to NULL, this could cause use-after-free bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/stm: Avoid use-after-free issues with crtc and plane<br /> <br /> ltdc_load() calls functions drm_crtc_init_with_planes(),<br /> drm_universal_plane_init() and drm_encoder_init(). These functions<br /> should not be called with parameters allocated with devm_kzalloc()<br /> to avoid use-after-free issues [1].<br /> <br /> Use allocations managed by the DRM framework.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).<br /> <br /> [1]<br /> https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: lantiq_etop: fix memory disclosure<br /> <br /> When applying padding, the buffer is not zeroed, which results in memory<br /> disclosure. The mentioned data is observed on the wire. This patch uses<br /> skb_put_padto() to pad Ethernet frames properly. The mentioned function<br /> zeroes the expanded buffer.<br /> <br /> In case the packet cannot be padded it is silently dropped. Statistics<br /> are also not incremented. This driver does not support statistics in the<br /> old 32-bit format or the new 64-bit format. These will be added in the<br /> future. In its current form, the patch should be easily backported to<br /> stable versions.<br /> <br /> Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets<br /> in hardware, so software padding must be applied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: improve shutdown sequence<br /> <br /> Alexander Sverdlin presents 2 problems during shutdown with the<br /> lan9303 driver. One is specific to lan9303 and the other just happens<br /> to reproduce there.<br /> <br /> The first problem is that lan9303 is unique among DSA drivers in that it<br /> calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown,<br /> not remove):<br /> <br /> phy_state_machine()<br /> -&gt; ...<br /> -&gt; dsa_user_phy_read()<br /> -&gt; ds-&gt;ops-&gt;phy_read()<br /> -&gt; lan9303_phy_read()<br /> -&gt; chip-&gt;ops-&gt;phy_read()<br /> -&gt; lan9303_mdio_phy_read()<br /> -&gt; dev_get_drvdata()<br /> <br /> But we never stop the phy_state_machine(), so it may continue to run<br /> after dsa_switch_shutdown(). Our common pattern in all DSA drivers is<br /> to set drvdata to NULL to suppress the remove() method that may come<br /> afterwards. But in this case it will result in an NPD.<br /> <br /> The second problem is that the way in which we set<br /> dp-&gt;conduit-&gt;dsa_ptr = NULL; is concurrent with receive packet<br /> processing. dsa_switch_rcv() checks once whether dev-&gt;dsa_ptr is NULL,<br /> but afterwards, rather than continuing to use that non-NULL value,<br /> dev-&gt;dsa_ptr is dereferenced again and again without NULL checks:<br /> dsa_conduit_find_user() and many other places. In between dereferences,<br /> there is no locking to ensure that what was valid once continues to be<br /> valid.<br /> <br /> Both problems have the common aspect that closing the conduit interface<br /> solves them.<br /> <br /> In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN<br /> event in dsa_user_netdevice_event() which closes user ports as well.<br /> dsa_port_disable_rt() calls phylink_stop(), which synchronously stops<br /> the phylink state machine, and ds-&gt;ops-&gt;phy_read() will thus no longer<br /> call into the driver after this point.<br /> <br /> In the second case, dev_close(conduit) should do this, as per<br /> Documentation/networking/driver.rst:<br /> <br /> | Quiescence<br /> | ----------<br /> |<br /> | After the ndo_stop routine has been called, the hardware must<br /> | not receive or transmit any data. All in flight packets must<br /> | be aborted. If necessary, poll or wait for completion of<br /> | any reset commands.<br /> <br /> So it should be sufficient to ensure that later, when we zeroize<br /> conduit-&gt;dsa_ptr, there will be no concurrent dsa_switch_rcv() call<br /> on this conduit.<br /> <br /> The addition of the netif_device_detach() function is to ensure that<br /> ioctls, rtnetlinks and ethtool requests on the user ports no longer<br /> propagate down to the driver - we&amp;#39;re no longer prepared to handle them.<br /> <br /> The race condition actually did not exist when commit 0650bf52b31f<br /> ("net: dsa: be compatible with masters which unregister on shutdown")<br /> first introduced dsa_switch_shutdown(). It was created later, when we<br /> stopped unregistering the user interfaces from a bad spot, and we just<br /> replaced that sequence with a racy zeroization of conduit-&gt;dsa_ptr<br /> (one which doesn&amp;#39;t ensure that the interfaces aren&amp;#39;t up).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Increase array size of dummy_boolean<br /> <br /> [WHY]<br /> dml2_core_shared_mode_support and dml_core_mode_support access the third<br /> element of dummy_boolean, i.e. hw_debug5 = &amp;s-&gt;dummy_boolean[2], when<br /> dummy_boolean has size of 2. Any assignment to hw_debug5 causes an<br /> OVERRUN.<br /> <br /> [HOW]<br /> Increase dummy_boolean&amp;#39;s array size to 3.<br /> <br /> This fixes 2 OVERRUN issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Deallocate DML memory if allocation fails<br /> <br /> [Why]<br /> When DC state create DML memory allocation fails, memory is not<br /> deallocated subsequently, resulting in uninitialized structure<br /> that is not NULL.<br /> <br /> [How]<br /> Deallocate memory if DML memory allocation fails.