Page 98 of 2942 results (0.008 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: MIPS: Octeon: Add PCIe link status check The standard PCIe configuration read-write interface is used to access the configuration space of the peripheral PCIe devices of the mips processor after the PCIe link surprise down, it can generate kernel panic caused by "Data bus error". So it is necessary to add PCIe link status check for system protection. When the PCIe link is down or in training, assigning a value of 0 to the configuration address can prevent read-write behavior to the configuration space of peripheral PCIe devices, thereby preventing kernel panic. • https://git.kernel.org/stable/c/6bff05aaa32c2f7e1f6e68e890876642159db419 https://git.kernel.org/stable/c/64845ac64819683ad5e51b668b2ed56ee3386aee https://git.kernel.org/stable/c/6c1b9fe148a4e03bbfa234267ebb89f35285814a https://git.kernel.org/stable/c/25998f5613159fe35920dbd484fcac7ea3ad0799 https://git.kernel.org/stable/c/d996deb80398a90dd3c03590e68dad543da87d62 https://git.kernel.org/stable/c/1c33fd17383f48f679186c54df78542106deeaa0 https://git.kernel.org/stable/c/38d647d509543e9434b3cc470b914348be271fe9 https://git.kernel.org/stable/c/29b83a64df3b42c88c0338696feb6fdcd •

CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: serial: imx: Introduce timeout when waiting on transmitter empty By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock. In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue. • https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7 https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916 https://git.kernel.org/stable/c/982ae3376c4c91590d38dc8a676c10f7df048a44 https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701 https://git.kernel.org/stable/c/e533e4c62e9993e62e947ae9bbec34e4c7ae81c2 https://access.redhat.com/security/cve/CVE-2024-40967 https://bugzilla.redhat.com/show_bug.cgi?id=2297551 • CWE-833: Deadlock •

CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: tty: add the option to have a tty reject a new ldisc ... and use it to limit the virtual terminals to just N_TTY. They are kind of special, and in particular, the "con_write()" routine violates the "writes cannot sleep" rule that some ldiscs rely on. This avoids the BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659 when N_GSM has been attached to a virtual console, and gsmld_write() calls con_write() while holding a spinlock, and con_write() then tries to get the console lock. • https://git.kernel.org/stable/c/3c6332f3bb1578b5b10ac2561247b1d6272ae937 https://git.kernel.org/stable/c/287b569a5b914903ba7c438a3c0dbc3410ebb409 https://git.kernel.org/stable/c/5920ac19964f9e20181f63b410d9200ddbf8dc86 https://git.kernel.org/stable/c/6bd23e0c2bb6c65d4f5754d1456bc9a4427fc59b https://access.redhat.com/security/cve/CVE-2024-40966 https://bugzilla.redhat.com/show_bug.cgi?id=2297550 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

CVSS: 4.4EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: i2c: lpi2c: Avoid calling clk_get_rate during transfer Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well. A vulnerability was found in the lpi2c driver in the Linux kernel's i2c subsystem, where the clk_get_rate function is called during data transfers, which can lead to a deadlock situation when an audio codec attempts to access the i2c bus while holding the clock mutex, resulting in a denial of service. • https://git.kernel.org/stable/c/2b42e9587a7a9c7b824e0feb92958f258263963e https://git.kernel.org/stable/c/4268254a39484fc11ba991ae148bacbe75d9cc0a https://access.redhat.com/security/cve/CVE-2024-40965 https://bugzilla.redhat.com/show_bug.cgi?id=2297549 • CWE-833: Deadlock •

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

In the Linux kernel, the following vulnerability has been resolved: drm/exynos/vidi: fix memory leak in .get_modes() The duplicated EDID is never freed. Fix it. • https://git.kernel.org/stable/c/540ca99729e28dbe902b01039a3b4bd74520a819 https://git.kernel.org/stable/c/ebcf81504fef03f701b9711e43fea4fe2d82ebc8 https://git.kernel.org/stable/c/0acc356da8546b5c55aabfc2e2c5caa0ac9b0003 https://git.kernel.org/stable/c/777838c9b571674ef14dbddf671f372265879226 https://git.kernel.org/stable/c/dcba6bedb439581145d8aa6b0925209f23184ae1 https://git.kernel.org/stable/c/a269c5701244db2722ae0fce5d1854f5d8f31224 https://git.kernel.org/stable/c/cb3ac233434dba130281db330c4b15665b2d2c4d https://git.kernel.org/stable/c/38e3825631b1f314b21e3ade00b5a4d73 •