CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42320 – s390/dasd: fix error checks in dasd_copy_pair_store()
https://notcve.org/view.php?id=CVE-2024-42320
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error checks in dasd_copy_pair_store() dasd_add_busid() can return an error via ERR_PTR() if an allocation fails. However, two callsites in dasd_copy_pair_store() do not check the result, potentially resulting in a NULL pointer dereference. Fix this by checking the result with IS_ERR() and returning the error up the stack. • https://git.kernel.org/stable/c/a91ff09d39f9b6545254839ac91f1ff7bd21d39e https://git.kernel.org/stable/c/932600a295cc299d470ca7f5d6491bd0dfc99ea7 https://git.kernel.org/stable/c/cc8b7284d5076722e0b8062373b68d8e47c3bace https://git.kernel.org/stable/c/e511167e65d332d07b3c7a3d5a741ee9c19a8c27 https://git.kernel.org/stable/c/68d4c3722290ad300c295fb3435e835d200d5cb2 https://git.kernel.org/stable/c/8e64d2356cbc800b4cd0e3e614797f76bcf0cdb8 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42319 – mailbox: mtk-cmdq: Move devm_mbox_controller_register() after devm_pm_runtime_enable()
https://notcve.org/view.php?id=CVE-2024-42319
In the Linux kernel, the following vulnerability has been resolved: mailbox: mtk-cmdq: Move devm_mbox_controller_register() after devm_pm_runtime_enable() When mtk-cmdq unbinds, a WARN_ON message with condition pm_runtime_get_sync() < 0 occurs. According to the call tracei below: cmdq_mbox_shutdown mbox_free_channel mbox_controller_unregister __devm_mbox_controller_unregister ... The root cause can be deduced to be calling pm_runtime_get_sync() after calling pm_runtime_disable() as observed below: 1. CMDQ driver uses devm_mbox_controller_register() in cmdq_probe() to bind the cmdq device to the mbox_controller, so devm_mbox_controller_unregister() will automatically unregister the device bound to the mailbox controller when the device-managed resource is removed. That means devm_mbox_controller_unregister() and cmdq_mbox_shoutdown() will be called after cmdq_remove(). 2. CMDQ driver also uses devm_pm_runtime_enable() in cmdq_probe() after devm_mbox_controller_register(), so that devm_pm_runtime_disable() will be called after cmdq_remove(), but before devm_mbox_controller_unregister(). To fix this problem, cmdq_probe() needs to move devm_mbox_controller_register() after devm_pm_runtime_enable() to make devm_pm_runtime_disable() be called after devm_mbox_controller_unregister(). • https://git.kernel.org/stable/c/623a6143a845bd485b00ba684f0ccef11835edab https://git.kernel.org/stable/c/11fa625b45faf0649118b9deaf2d31c86ac41911 https://git.kernel.org/stable/c/a8bd68e4329f9a0ad1b878733e0f80be6a971649 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42318 – landlock: Don't lose track of restrictions on cred_transfer
https://notcve.org/view.php?id=CVE-2024-42318
In the Linux kernel, the following vulnerability has been resolved: landlock: Don't lose track of restrictions on cred_transfer When a process' cred struct is replaced, this _almost_ always invokes the cred_prepare LSM hook; but in one special case (when KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the cred_transfer LSM hook is used instead. Landlock only implements the cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes all information on Landlock restrictions to be lost. This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself. Fix it by adding a cred_transfer hook that does the same thing as the existing cred_prepare hook. (Implemented by having hook_cred_prepare() call hook_cred_transfer() so that the two functions are less likely to accidentally diverge in the future.) Linux has an issue where landlock can be disabled thanks to a missing cred_transfer hook. • https://git.kernel.org/stable/c/385975dca53eb41031d0cbd1de318eb1bc5d6bb9 https://git.kernel.org/stable/c/916c648323fa53b89eedb34a0988ddaf01406117 https://git.kernel.org/stable/c/0d74fd54db0bd0c0c224bef0da8fc95ea9c9f36c https://git.kernel.org/stable/c/16896914bace82d7811c62f3b6d5320132384f49 https://git.kernel.org/stable/c/b14cc2cf313bd29056fadbc8ecd7f957cf5791ff https://git.kernel.org/stable/c/39705a6c29f8a2b93cf5b99528a55366c50014d1 https://lore.kernel.org/all/20240817.shahka3Ee1iy@digikod.net https://www.openwall.com/lists/oss-security/2024/08/17& •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42315 – exfat: fix potential deadlock on __exfat_get_dentry_set
https://notcve.org/view.php?id=CVE-2024-42315
In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential deadlock on __exfat_get_dentry_set When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set. The problem is that the bh-array is allocated with GFP_KERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur. CPU0 CPU1 ---- ---- kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... evict exfat_evict_inode lock(&sbi->s_lock) To fix this, let's allocate bh-array with GFP_NOFS. • https://git.kernel.org/stable/c/a3ff29a95fde16906304455aa8c0bd84eb770258 https://git.kernel.org/stable/c/bd3bdb9e0d656f760b11d0c638d35d7f7068144d https://git.kernel.org/stable/c/92dcd7d6c6068bf4fd35a6f64d606e27d634807e https://git.kernel.org/stable/c/a7ac198f8dba791e3144c4da48a5a9b95773ee4b https://git.kernel.org/stable/c/1d1970493c289e3f44b9ec847ed26a5dbdf56a62 https://git.kernel.org/stable/c/89fc548767a2155231128cb98726d6d2ea1256c9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42313 – media: venus: fix use after free in vdec_close
https://notcve.org/view.php?id=CVE-2024-42313
In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free in vdec_close There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst. Fix it by cancelling the work in vdec_close. • https://git.kernel.org/stable/c/af2c3834c8ca7cc65d15592ac671933df8848115 https://git.kernel.org/stable/c/ad8cf035baf29467158e0550c7a42b7bb43d1db6 https://git.kernel.org/stable/c/72aff311194c8ceda934f24fd6f250b8827d7567 https://git.kernel.org/stable/c/4c9d235630d35db762b85a4149bbb0be9d504c36 https://git.kernel.org/stable/c/f8e9a63b982a8345470c225679af4ba86e4a7282 https://git.kernel.org/stable/c/da55685247f409bf7f976cc66ba2104df75d8dad https://git.kernel.org/stable/c/66fa52edd32cdbb675f0803b3c4da10ea19b6635 https://git.kernel.org/stable/c/6a96041659e834dc0b172dda4b2df512d •