CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-42093 – net/dpaa2: Avoid explicit cpumask var allocation on stack
https://notcve.org/view.php?id=CVE-2024-42093
In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. • https://git.kernel.org/stable/c/b2262b3be27cee334a2fa175ae3afb53f38fb0b1 https://git.kernel.org/stable/c/763896ab62a672d728f5eb10ac90d98c607a8509 https://git.kernel.org/stable/c/a55afc0f5f20ba30970aaf7271929dc00eee5e7d https://git.kernel.org/stable/c/48147337d7efdea6ad6e49f5b8eb894b95868ef0 https://git.kernel.org/stable/c/69f49527aea12c23b78fb3d0a421950bf44fb4e2 https://git.kernel.org/stable/c/5e4f25091e6d06e99a23f724c839a58a8776a527 https://git.kernel.org/stable/c/d33fe1714a44ff540629b149d8fab4ac6967585c •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42092 – gpio: davinci: Validate the obtained number of IRQs
https://notcve.org/view.php?id=CVE-2024-42092
In the Linux kernel, the following vulnerability has been resolved: gpio: davinci: Validate the obtained number of IRQs Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe(). Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/eb3744a2dd01cb07ce9f556d56d6fe451f0c313a https://git.kernel.org/stable/c/a8d78984fdc105bc1a38b73e98d32b1bc4222684 https://git.kernel.org/stable/c/cd75721984337c38a12aeca33ba301d31ca4b3fd https://git.kernel.org/stable/c/e44a83bf15c4db053ac6dfe96a23af184c9136d9 https://git.kernel.org/stable/c/70b48899f3f23f98a52c5b1060aefbdc7ba7957b https://git.kernel.org/stable/c/89d7008af4945808677662a630643b5ea89c6e8d https://git.kernel.org/stable/c/2d83492259ad746b655f196cd5d1be4b3d0a3782 https://git.kernel.org/stable/c/c542e51306d5f1eba3af84daa00582622 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42091 – drm/xe: Check pat.ops before dumping PAT settings
https://notcve.org/view.php?id=CVE-2024-42091
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Check pat.ops before dumping PAT settings We may leave pat.ops unset when running on brand new platform or when running as a VF. While the former is unlikely, the latter is valid (future) use case and will cause NPD when someone will try to dump PAT settings by debugfs. It's better to check pointer to pat.ops instead of specific .dump hook, as we have this hook always defined for every .ops variant. • https://git.kernel.org/stable/c/583ce246c7ff9edeb0de49130cdc3d45db8545cb https://git.kernel.org/stable/c/a918e771e6fbe1fa68932af5b0cdf473e23090cc •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42090 – pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
https://notcve.org/view.php?id=CVE-2024-42090
In the Linux kernel, the following vulnerability has been resolved: pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock. This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. • https://git.kernel.org/stable/c/42fed7ba44e4e8c1fb27b28ad14490cb1daff3c7 https://git.kernel.org/stable/c/e65a0dc2e85efb28e182aca50218e8a056d0ce04 https://git.kernel.org/stable/c/420ce1261907e5dbeda1e4daffd5b6c76f8188c0 https://git.kernel.org/stable/c/b813e3fd102a959c5b208ed68afe27e0137a561b https://git.kernel.org/stable/c/01fe2f885f7813f8aed5d3704b384a97b1116a9e https://git.kernel.org/stable/c/b36efd2e3e22a329444b6b24fa48df6d20ae66e6 https://git.kernel.org/stable/c/4038c57bf61631219b31f1bd6e92106ec7f084dc https://git.kernel.org/stable/c/48a7a7c9571c3e62f17012dd7f2063e92 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42089 – ASoC: fsl-asoc-card: set priv->pdev before using it
https://notcve.org/view.php?id=CVE-2024-42089
In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl-asoc-card: set priv->pdev before using it priv->pdev pointer was set after being used in fsl_asoc_card_audmux_init(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv. fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations. • https://git.kernel.org/stable/c/708b4351f08c08ea93f773fb9197bdd3f3b08273 https://git.kernel.org/stable/c/ae81535ce2503aabc4adab3472f4338070cdeb6a https://git.kernel.org/stable/c/8896e18b7c366f8faf9344abfd0971435f1c723a https://git.kernel.org/stable/c/3662eb2170e59b58ad479982dc1084889ba757b9 https://git.kernel.org/stable/c/544ab46b7ece6d6bebbdee5d5659c0a0f804a99a https://git.kernel.org/stable/c/8faf91e58425c2f6ce773250dfd995f1c2d461ac https://git.kernel.org/stable/c/29bc9e7c75398b0d12fc30955f2e9b2dd29ffaed https://git.kernel.org/stable/c/7c18b4d89ff9c810b6e562408afda5ce1 •