CVE-2024-40966 – tty: add the option to have a tty reject a new ldisc
https://notcve.org/view.php?id=CVE-2024-40966
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') •
CVE-2024-40965 – i2c: lpi2c: Avoid calling clk_get_rate during transfer
https://notcve.org/view.php?id=CVE-2024-40965
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 •
CVE-2024-40932 – drm/exynos/vidi: fix memory leak in .get_modes()
https://notcve.org/view.php?id=CVE-2024-40932
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 •
CVE-2024-40918 – parisc: Try to fix random segmentation faults in package builds
https://notcve.org/view.php?id=CVE-2024-40918
In the Linux kernel, the following vulnerability has been resolved: parisc: Try to fix random segmentation faults in package builds PA-RISC systems with PA8800 and PA8900 processors have had problems with random segmentation faults for many years. Systems with earlier processors are much more stable. Systems with PA8800 and PA8900 processors have a large L2 cache which needs per page flushing for decent performance when a large range is flushed. The combined cache in these systems is also more sensitive to non-equivalent aliases than the caches in earlier systems. The majority of random segmentation faults that I have looked at appear to be memory corruption in memory allocated using mmap and malloc. My first attempt at fixing the random faults didn't work. On reviewing the cache code, I realized that there were two issues which the existing code didn't handle correctly. Both relate to cache move-in. • https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0 https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20 https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49 •
CVE-2024-40902 – jfs: xattr: fix buffer overflow for invalid xattr
https://notcve.org/view.php?id=CVE-2024-40902
In the Linux kernel, the following vulnerability has been resolved: jfs: xattr: fix buffer overflow for invalid xattr When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jfs: xattr: corrige el desbordamiento del búfer para xattr no válido Cuando un tamaño de xattr no es el esperado, se imprime en el registro del kernel en formato hexadecimal como una forma de depuración. Pero cuando el tamaño de xattr es mayor que el tamaño esperado, imprimirlo puede provocar un acceso desde el final del búfer. Solucione todo esto restringiendo adecuadamente el tamaño del volcado hexadecimal de depuración en el registro del kernel. • https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0 https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7 https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123 https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69 https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •