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-40964 – ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()
https://notcve.org/view.php?id=CVE-2024-40964
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind() The cs35l41_hda_unbind() function clears the hda_component entry matching it's index and then dereferences the codec pointer held in the first element of the hda_component array, this is an issue when the device index was 0. Instead use the codec pointer stashed in the cs35l41_hda structure as it will still be valid. • https://git.kernel.org/stable/c/7cf5ce66dfda2be444ea668c3d48f732ba4a7fd1 https://git.kernel.org/stable/c/ff27bd8e17884f7cdefecb3f3817caadd6813dc0 https://git.kernel.org/stable/c/19be722369c347f3af1c5848e303980ed040b819 https://git.kernel.org/stable/c/6386682cdc8b41319c92fbbe421953e33a28840c •
CVE-2024-40963 – mips: bmips: BCM6358: make sure CBR is correctly set
https://notcve.org/view.php?id=CVE-2024-40963
In the Linux kernel, the following vulnerability has been resolved: mips: bmips: BCM6358: make sure CBR is correctly set It was discovered that some device have CBR address set to 0 causing kernel panic when arch_sync_dma_for_cpu_all is called. This was notice in situation where the system is booted from TP1 and BMIPS_GET_CBR() returns 0 instead of a valid address and !!(read_c0_brcm_cmt_local() & (1 << 31)); not failing. The current check whether RAC flush should be disabled or not are not enough hence lets check if CBR is a valid address or not. • https://git.kernel.org/stable/c/d65de5ee8b72868fbbbd39ca73017d0e526fa13a https://git.kernel.org/stable/c/47a449ec09b4479b89dcc6b27ec3829fc82ffafb https://git.kernel.org/stable/c/65b723644294f1d79770704162c0e8d1f700b6f1 https://git.kernel.org/stable/c/2cdbcff99f15db86a10672fb220379a1ae46ccae https://git.kernel.org/stable/c/ab327f8acdf8d06601fbf058859a539a9422afff https://git.kernel.org/stable/c/288c96aa5b5526cd4a946e84ef85e165857693b5 https://git.kernel.org/stable/c/10afe5f7d30f6fe50c2b1177549d0e04921fc373 https://git.kernel.org/stable/c/36d771ce6028b886e18a4a8956a5d2368 •
CVE-2024-40962 – btrfs: zoned: allocate dummy checksums for zoned NODATASUM writes
https://notcve.org/view.php?id=CVE-2024-40962
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: allocate dummy checksums for zoned NODATASUM writes Shin'ichiro reported that when he's running fstests' test-case btrfs/167 on emulated zoned devices, he's seeing the following NULL pointer dereference in 'btrfs_zone_finish_endio()': Oops: general protection fault, probably for non-canonical address 0xdffffc0000000011: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 4 PID: 2332440 Comm: kworker/u80:15 Tainted: G W 6.10.0-rc2-kts+ #4 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] RSP: 0018:ffff88867f107a90 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff893e5534 RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088 RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed1081696028 R10: ffff88840b4b0143 R11: ffff88834dfff600 R12: ffff88840b4b0000 R13: 0000000000020000 R14: 0000000000000000 R15: ffff888530ad5210 FS: 0000000000000000(0000) GS:ffff888e3f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f87223fff38 CR3: 00000007a7c6a002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die_addr+0x46/0x70 ? exc_general_protection+0x14f/0x250 ? asm_exc_general_protection+0x26/0x30 ? • https://git.kernel.org/stable/c/cbfce4c7fbde23cc8bcba44822a58c728caf6ec9 https://git.kernel.org/stable/c/082b3d4e788953a3ff42ecdb70c4210149076285 https://git.kernel.org/stable/c/25cfe59f4470a051d1b80f51fa0ca3a5048e4a19 https://git.kernel.org/stable/c/cebae292e0c32a228e8f2219c270a7237be24a6a •