CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46695 – selinux,smack: don't bypass permissions check in inode_setsecctx hook
https://notcve.org/view.php?id=CVE-2024-46695
In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label. • https://git.kernel.org/stable/c/459584258d47ec3cc6245a82e8a49c9d08eb8b57 https://git.kernel.org/stable/c/f71ec019257ba4f7ab198bd948c5902a207bad96 https://git.kernel.org/stable/c/76a0e79bc84f466999fa501fce5bf7a07641b8a7 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-46694 – drm/amd/display: avoid using null object of framebuffer
https://notcve.org/view.php?id=CVE-2024-46694
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. (cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3) • https://git.kernel.org/stable/c/5d945cbcd4b16a29d6470a80dfb19738f9a4319f https://git.kernel.org/stable/c/c46dda486e4f9b86eeac40aaea65a6f93dc44dad https://git.kernel.org/stable/c/093ee72ed35c2338c87c26b6ba6f0b7789c9e14e https://git.kernel.org/stable/c/f6f5e39a3fe7cbdba190f42b28b40bdff03c8cf0 https://git.kernel.org/stable/c/49e1b214f3239b78967c6ddb8f8ec47ae047b051 https://git.kernel.org/stable/c/3b9a33235c773c7a3768060cf1d2cf8a9153bc37 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46693 – soc: qcom: pmic_glink: Fix race during initialization
https://notcve.org/view.php?id=CVE-2024-46693
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pmic_glink: Fix race during initialization As pointed out by Stephen Boyd it is possible that during initialization of the pmic_glink child drivers, the protection-domain notifiers fires, and the associated work is scheduled, before the client registration returns and as a result the local "client" pointer has been initialized. The outcome of this is a NULL pointer dereference as the "client" pointer is blindly dereferenced. Timeline provided by Stephen: CPU0 CPU1 ---- ---- ucsi->client = NULL; devm_pmic_glink_register_client() client->pdr_notify(client->priv, pg->client_state) pmic_glink_ucsi_pdr_notify() schedule_work(&ucsi->register_work) <schedule away> pmic_glink_ucsi_register() ucsi_register() pmic_glink_ucsi_read_version() pmic_glink_ucsi_read() pmic_glink_ucsi_read() pmic_glink_send(ucsi->client) <client is NULL BAD> ucsi->client = client // Too late! This code is identical across the altmode, battery manager and usci child drivers. Resolve this by splitting the allocation of the "client" object and the registration thereof into two operations. This only happens if the protection domain registry is populated at the time of registration, which by the introduction of commit '1ebcde047c54 ("soc: qcom: add pd-mapper implementation")' became much more likely. • https://git.kernel.org/stable/c/58ef4ece1e41ac525db3e79529909683325d85df https://git.kernel.org/stable/c/1efdbf5323c9360e05066049b97414405e94e087 https://git.kernel.org/stable/c/943b0e7cc646a624bb20a68080f8f1a4a55df41c https://git.kernel.org/stable/c/3568affcddd68743e25aa3ec1647d9b82797757b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46692 – firmware: qcom: scm: Mark get_wq_ctx() as atomic call
https://notcve.org/view.php?id=CVE-2024-46692
In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: Mark get_wq_ctx() as atomic call Currently get_wq_ctx() is wrongly configured as a standard call. When two SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to resume the corresponding sleeping thread. But if get_wq_ctx() is interrupted, goes to sleep and another SMC call is waiting to be allocated a waitq context, it leads to a deadlock. To avoid this get_wq_ctx() must be an atomic call and can't be a standard SMC call. Hence mark get_wq_ctx() as a fast call. • https://git.kernel.org/stable/c/6bf32599223634294cdc6efb359ffaab1d68073c https://git.kernel.org/stable/c/cdf7efe4b02aa93813db0bf1ca596ad298ab6b06 https://git.kernel.org/stable/c/e40115c33c0d79c940545b6b12112aace7acd9f5 https://git.kernel.org/stable/c/9960085a3a82c58d3323c1c20b991db6045063b0 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-46691 – usb: typec: ucsi: Move unregister out of atomic section
https://notcve.org/view.php?id=CVE-2024-46691
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Move unregister out of atomic section Commit '9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping")' moved the pmic_glink client list under a spinlock, as it is accessed by the rpmsg/glink callback, which in turn is invoked from IRQ context. This means that ucsi_unregister() is now called from atomic context, which isn't feasible as it's expecting a sleepable context. An effort is under way to get GLINK to invoke its callbacks in a sleepable context, but until then lets schedule the unregistration. A side effect of this is that ucsi_unregister() can now happen after the remote processor, and thereby the communication link with it, is gone. pmic_glink_send() is amended with a check to avoid the resulting NULL pointer dereference. This does however result in the user being informed about this error by the following entry in the kernel log: ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5 • https://git.kernel.org/stable/c/9329933699b32d467a99befa20415c4b2172389a https://git.kernel.org/stable/c/fbadcde1572f6b00e1e343d8b24ec8bf7f3ec08d https://git.kernel.org/stable/c/8d62ab7d89a4906385ea8c11a4b2475578bec0f0 https://git.kernel.org/stable/c/bd54d7c8e76d235b4a70be3a545eb13f5ac531e4 https://git.kernel.org/stable/c/095b0001aefddcd9361097c971b7debc84e72714 https://git.kernel.org/stable/c/11bb2ffb679399f99041540cf662409905179e3a •