CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56634 – gpio: grgpio: Add NULL check in grgpio_probe
https://notcve.org/view.php?id=CVE-2024-56634
In the Linux kernel, the following vulnerability has been resolved: gpio: grgpio: Add NULL check in grgpio_probe devm_kasprintf() can return a NULL pointer on failure,but this returned value in grgpio_probe is not checked. Add NULL check in grgpio_probe, to handle kernel NULL pointer dereference error. • https://git.kernel.org/stable/c/7eb6ce2f272336ff8337f40fa8668fa04dc2d684 https://git.kernel.org/stable/c/53ff0caa6ad57372d426b4f48fc0f66df43a731f https://git.kernel.org/stable/c/4733f68e59bb7b9e3d395699abb18366954b9ba7 https://git.kernel.org/stable/c/ad4dfa7ea7f5f7e9a3c78627cfc749bc7005ca7a https://git.kernel.org/stable/c/09adf8792b61c09ae543972a1ece1884ef773848 https://git.kernel.org/stable/c/8d2ca6ac3711a4f4015d26b7cc84f325ac608edb https://git.kernel.org/stable/c/db2fc255fcf41f536ac8666409849e11659af88d https://git.kernel.org/stable/c/050b23d081da0f29474de043e9538c1f7 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56633 – tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg
https://notcve.org/view.php?id=CVE-2024-56633
In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging tosend bytes, which is either msg->sg.size or a smaller value apply_bytes. Potential problems with this strategy are as follows: - If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean. - When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes. [...] 415 tosend = msg->sg.size; 416 if (psock->apply_bytes && psock->apply_bytes < tosend) 417 tosend = psock->apply_bytes; [...] 443 sk_msg_return(sk, msg, tosend); 444 release_sock(sk); 446 origsize = msg->sg.size; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448 msg, tosend, flags); 449 sent = origsize - msg->sg.size; [...] 454 lock_sock(sk); 455 if (unlikely(ret < 0)) { 456 int free = sk_msg_free_nocharge(sk, msg); 458 if (!cork) 459 *copied -= free; 460 } [...] 487 if (eval == __SK_REDIRECT) 488 sk_mem_charge(sk, tosend - sent); [...] When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply, the following warning will be reported: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events sk_psock_destroy RIP: 0010:inet_sock_destruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x89/0x130 ? inet_sock_destruct+0x190/0x1a0 ? report_bug+0xfc/0x1e0 ? • https://git.kernel.org/stable/c/604326b41a6fb9b4a78b6179335decee0365cd8c https://git.kernel.org/stable/c/905d82e6e77d16ec3e089c92b7b59a14899dfc1a https://git.kernel.org/stable/c/dbedc7e142df5ea238a46fdd7462c1c42cd36a10 https://git.kernel.org/stable/c/0d6cd1151e26fc7c2d5daa85e8984aaa685a1a12 https://git.kernel.org/stable/c/456f08d24afa51b5eb816c42e4ca1c44a247bd42 https://git.kernel.org/stable/c/206d56f41a1509cadd06e2178c26cb830e45057d https://git.kernel.org/stable/c/5c9e3bb43a354a2245caebbbbb4a5b8c034fdd56 https://git.kernel.org/stable/c/ca70b8baf2bd125b2a4d96e76db79375c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56632 – nvme-tcp: fix the memleak while create new ctrl failed
https://notcve.org/view.php?id=CVE-2024-56632
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix the memleak while create new ctrl failed Now while we create new ctrl failed, we have not free the tagset occupied by admin_q, here try to fix it. • https://git.kernel.org/stable/c/fd1418de10b9ca03d78404cf00a95138689ea369 https://git.kernel.org/stable/c/ceff9ac13a2478afddce85414d404e6aff6425f6 https://git.kernel.org/stable/c/fec55c29e54d3ca6fe9d7d7d9266098b4514fd34 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56631 – scsi: sg: Fix slab-use-after-free read in sg_release()
https://notcve.org/view.php?id=CVE-2024-56631
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Fix slab-use-after-free read in sg_release() Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407 In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp. After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error. Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. - Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release(). The fix has been tested and validated by syzbot. • https://git.kernel.org/stable/c/cc833acbee9db5ca8c6162b015b4c93863c6f821 https://git.kernel.org/stable/c/3a27c0defb0315760100f8b1adc7c4acbe04c884 https://git.kernel.org/stable/c/59b30afa578637169e2819536bb66459fdddc39d https://git.kernel.org/stable/c/1f5e2f1ca5875728fcf62bc1a054707444ab4960 https://git.kernel.org/stable/c/f10593ad9bc36921f623361c9e3dd96bd52d85ee •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56630 – ocfs2: free inode when ocfs2_get_init_inode() fails
https://notcve.org/view.php?id=CVE-2024-56630
In the Linux kernel, the following vulnerability has been resolved: ocfs2: free inode when ocfs2_get_init_inode() fails syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826 ("ocfs2: Handle error from dquot_initialize()") forgot to call iput() when new_inode() succeeded and dquot_initialize() failed. • https://git.kernel.org/stable/c/9c89fe0af826bfff36d8019ea6fd78db09b3c478 https://git.kernel.org/stable/c/911fcc95b530615b484e8920741fc5e4bc4e684a https://git.kernel.org/stable/c/9c19ea59965ebb482e227532f7bbb01792fb028c https://git.kernel.org/stable/c/c5327720a4655303ffa3f632d86ee205dd783f32 https://git.kernel.org/stable/c/67c2c6d0564ca05348ba4f8f6eaf7a0713f56c15 https://git.kernel.org/stable/c/a84d507d3290aca249b44ae992af9e10590cc5f6 https://git.kernel.org/stable/c/03db61c43c8e2729896fda6b9a95c7fb5c875c20 https://git.kernel.org/stable/c/965b5dd1894f4525f38c1b5f99b0106a0 •