Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> android: binder: stop saving a pointer to the VMA<br /> <br /> Do not record a pointer to a VMA outside of the mmap_lock for later use. <br /> This is unsafe and there are a number of failure paths *after* the<br /> recorded VMA pointer may be freed during setup. There is no callback to<br /> the driver to clear the saved pointer from generic mm code. Furthermore,<br /> the VMA pointer may become stale if any number of VMA operations end up<br /> freeing the VMA so saving it was fragile to being with.<br /> <br /> Instead, change the binder_alloc struct to record the start address of the<br /> VMA and use vma_lookup() to get the vma when needed. Add lockdep<br /> mmap_lock checks on updates to the vma pointer to ensure the lock is held<br /> and depend on that lock for synchronization of readers and writers - which<br /> was already the case anyways, so the smp_wmb()/smp_rmb() was not<br /> necessary.<br /> <br /> [akpm@linux-foundation.org: fix drivers/android/binder_alloc_selftest.c]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: fix use-after-free on source server when doing inter-server copy<br /> <br /> Use-after-free occurred when the laundromat tried to free expired<br /> cpntf_state entry on the s2s_cp_stateids list after inter-server<br /> copy completed. The sc_cp_list that the expired copy state was<br /> inserted on was already freed.<br /> <br /> When COPY completes, the Linux client normally sends LOCKU(lock_state x),<br /> FREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server.<br /> The nfs4_put_stid call from nfsd4_free_stateid cleans up the copy state<br /> from the s2s_cp_stateids list before freeing the lock state&amp;#39;s stid.<br /> <br /> However, sometimes the CLOSE was sent before the FREE_STATEID request.<br /> When this happens, the nfsd4_close_open_stateid call from nfsd4_close<br /> frees all lock states on its st_locks list without cleaning up the copy<br /> state on the sc_cp_list list. When the time the FREE_STATEID arrives the<br /> server returns BAD_STATEID since the lock state was freed. This causes<br /> the use-after-free error to occur when the laundromat tries to free<br /> the expired cpntf_state.<br /> <br /> This patch adds a call to nfs4_free_cpntf_statelist in<br /> nfsd4_close_open_stateid to clean up the copy state before calling<br /> free_ol_stateid_reaplist to free the lock state&amp;#39;s stid on the reaplist.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init()<br /> <br /> If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp<br /> needs to be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: handle the error returned from sctp_auth_asoc_init_active_key<br /> <br /> When it returns an error from sctp_auth_asoc_init_active_key(), the<br /> active_key is actually not updated. The old sh_key will be freeed<br /> while it&amp;#39;s still used as active key in asoc. Then an use-after-free<br /> will be triggered when sending patckets, as found by syzbot:<br /> <br /> sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112<br /> sctp_set_owner_w net/sctp/socket.c:132 [inline]<br /> sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863<br /> sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025<br /> inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:734<br /> <br /> This patch is to fix it by not replacing the sh_key when it returns<br /> errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().<br /> For sctp_auth_set_active_key(), old active_key_id will be set back<br /> to asoc-&gt;active_key_id when the same thing happens.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()<br /> <br /> If device_register() fails in cxl_pci_afu|adapter(), the device<br /> is not added, device_unregister() can not be called in the error<br /> path, otherwise it will cause a null-ptr-deref because of removing<br /> not added device.<br /> <br /> As comment of device_register() says, it should use put_device() to give<br /> up the reference in the error path. So split device_unregister() into<br /> device_del() and put_device(), then goes to put dev when register fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rapidio: fix possible UAF when kfifo_alloc() fails<br /> <br /> If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free<br /> priv. But priv is still in the chdev-&gt;file_list, then list traversal<br /> may cause UAF. This fixes the following smatch warning:<br /> <br /> drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: &amp;#39;&amp;priv-&gt;list&amp;#39; not removed from list

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/af_unix: defer registered files gc to io_uring release<br /> <br /> Instead of putting io_uring&amp;#39;s registered files in unix_gc() we want it<br /> to be done by io_uring itself. The trick here is to consider io_uring<br /> registered files for cycle detection but not actually putting them down.<br /> Because io_uring can&amp;#39;t register other ring instances, this will remove<br /> all refs to the ring file triggering the -&gt;release path and clean up<br /> with io_ring_ctx_free().<br /> <br /> [axboe: add kerneldoc comment to skb, fold in skb leak fix]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Protect against send buffer overflow in NFSv2 READDIR<br /> <br /> Restore the previous limit on the @count argument to prevent a<br /> buffer overflow attack.

Elevation of Privileges in the cleaning feature of Gen Digital CCleaner version 6.33.11465 on Windows allows a local user to gain SYSTEM privileges via exploiting insecure file delete operations. Reported in CCleaner v. 6.33.11465. This issue affects CCleaner: before

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/crypto: arm/poly1305: Fix register corruption in no-SIMD contexts<br /> <br /> Restore the SIMD usability check that was removed by commit 773426f4771b<br /> ("crypto: arm/poly1305 - Add block-only interface").<br /> <br /> This safety check is cheap and is well worth eliminating a footgun.<br /> While the Poly1305 functions should not be called when SIMD registers<br /> are unusable, if they are anyway, they should just do the right thing<br /> instead of corrupting random tasks&amp;#39; registers and/or computing incorrect<br /> MACs. Fixing this is also needed for poly1305_kunit to pass.<br /> <br /> Just use may_use_simd() instead of the original crypto_simd_usable(),<br /> since poly1305_kunit won&amp;#39;t rely on crypto_simd_disabled_for_test.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Remove WARN_ON_ONCE() call from ufshcd_uic_cmd_compl()<br /> <br /> The UIC completion interrupt may be disabled while an UIC command is<br /> being processed. When the UIC completion interrupt is reenabled, an UIC<br /> interrupt is triggered and the WARN_ON_ONCE(!cmd) statement is hit.<br /> Hence this patch that removes this kernel warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts<br /> <br /> Restore the SIMD usability check that was removed by commit a59e5468a921<br /> ("crypto: arm64/poly1305 - Add block-only interface").<br /> <br /> This safety check is cheap and is well worth eliminating a footgun.<br /> While the Poly1305 functions should not be called when SIMD registers<br /> are unusable, if they are anyway, they should just do the right thing<br /> instead of corrupting random tasks&amp;#39; registers and/or computing incorrect<br /> MACs. Fixing this is also needed for poly1305_kunit to pass.<br /> <br /> Just use may_use_simd() instead of the original crypto_simd_usable(),<br /> since poly1305_kunit won&amp;#39;t rely on crypto_simd_disabled_for_test.