CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-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. • https://git.kernel.org/stable/c/2b42e9587a7a9c7b824e0feb92958f258263963e https://git.kernel.org/stable/c/4268254a39484fc11ba991ae148bacbe75d9cc0a •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-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 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-40961 – ipv6: prevent possible NULL deref in fib6_nh_init()
https://notcve.org/view.php?id=CVE-2024-40961
In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible NULL deref in fib6_nh_init() syzbot reminds us that in6_dev_get() can return NULL. fib6_nh_init() ip6_validate_gw( &idev ) ip6_route_check_nh( idev ) *idev = in6_dev_get(dev); // can be NULL Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606 Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b RSP: 0018:ffffc900032775a0 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8 RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000 R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8 R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000 FS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809 ip6_route_add+0x28/0x160 net/ipv6/route.c:3853 ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483 inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f940f07cea9 • https://git.kernel.org/stable/c/428604fb118facce1309670779a35baf27ad044c https://git.kernel.org/stable/c/3200ffeec4d59aad5bc9ca75d2c1fae47c0aeade https://git.kernel.org/stable/c/de5ad4d45cd0128a2a37555f48ab69aa19d78adc https://git.kernel.org/stable/c/4cdfe813015d5a24586bd0a84fa0fa6eb0a1f668 https://git.kernel.org/stable/c/88b9a55e2e35ea846d41f4efdc29d23345bd1aa4 https://git.kernel.org/stable/c/b6947723c9eabcab58cfb33cdb0a565a6aee6727 https://git.kernel.org/stable/c/ae8d3d39efe366c2198f530e01e4bf07830bf403 https://git.kernel.org/stable/c/2eab4543a2204092c3a7af81d7d6c506e • CWE-476: NULL Pointer Dereference •