Page 162 of 5366 results (0.010 seconds)

CVSS: 5.2EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/iucv: 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/2b085521be5292016097b5e7ca81b26be3f7098d https://git.kernel.org/stable/c/842afb47d84536fc976fece8fb6c54bea711ad1a https://git.kernel.org/stable/c/9dadab0db7d904413ea1cdaa13f127da05c31e71 https://git.kernel.org/stable/c/0af718a690acc089aa1bbb95a93df833d864ef53 https://git.kernel.org/stable/c/d85ca8179a54ff8cf1e1f8c3c9e3799831319bae https://git.kernel.org/stable/c/724e7965af054079242b8d6f7e50ee226730a756 https://git.kernel.org/stable/c/2d090c7f7be3b26fcb80ac04d08a4a8062b1d959 https://git.kernel.org/stable/c/be4e1304419c99a164b4c0e101c7c2a75 • CWE-121: Stack-based Buffer Overflow •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

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: 0

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: 4.7EPSS: 0%CPEs: 8EXPL: 0

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. A deadlock flaw was found in the Linux kernel’s pinctrl subsystem. This flaw allows a local user to crash the system. • 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 • CWE-833: Deadlock •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

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 •