CVSS: 4.4EPSS: 0%CPEs: 1EXPL: 0CVE-2024-41008 – drm/amdgpu: change vm->task_info handling
https://notcve.org/view.php?id=CVE-2024-41008
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: change vm->task_info handling This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm. This patch also does logistical changes required for existing usage of vm->task_info. V2: Do not block all the prints when task_info not found (Felix) V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini() V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting • https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c https://access.redhat.com/security/cve/CVE-2024-41008 https://bugzilla.redhat.com/show_bug.cgi?id=2298079 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 4.7EPSS: 0%CPEs: 6EXPL: 0CVE-2024-41005 – netpoll: Fix race condition in netpoll_owner_active
https://notcve.org/view.php?id=CVE-2024-41005
In the Linux kernel, the following vulnerability has been resolved: netpoll: Fix race condition in netpoll_owner_active KCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) <snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock. Use an atomic read to check if the poll owner is the current CPU. • https://git.kernel.org/stable/c/43c0ca793a18578a0f5b305dd77fcf7ed99f1265 https://git.kernel.org/stable/c/efd29cd9c7b8369dfc7bcb34637e6bf1a188aa8e https://git.kernel.org/stable/c/96826b16ef9c6568d31a1f6ceaa266411a46e46c https://git.kernel.org/stable/c/3f1a155950a1685ffd0fd7175b3f671da8771f3d https://git.kernel.org/stable/c/a130e7da73ae93afdb4659842267eec734ffbd57 https://git.kernel.org/stable/c/c2e6a872bde9912f1a7579639c5ca3adf1003916 https://access.redhat.com/security/cve/CVE-2024-41005 https://bugzilla.redhat.com/show_bug.cgi?id=2297589 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-41002 – crypto: hisilicon/sec - Fix memory leak for sec resource release
https://notcve.org/view.php?id=CVE-2024-41002
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - Fix memory leak for sec resource release The AIV is one of the SEC resources. When releasing resources, it need to release the AIV resources at the same time. Otherwise, memory leakage occurs. The aiv resource release is added to the sec resource release function. • https://git.kernel.org/stable/c/a886bcb0f67d1e3d6b2da25b3519de59098200c2 https://git.kernel.org/stable/c/7c42ce556ff65995c8875c9ed64141c14238e7e6 https://git.kernel.org/stable/c/9f21886370db451b0fdc651f6e41550a1da70601 https://git.kernel.org/stable/c/36810d2db3496bb8b4db7ccda666674a5efc7b47 https://git.kernel.org/stable/c/bba4250757b4ae1680fea435a358d8093f254094 •
CVSS: 5.1EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41001 – io_uring/sqpoll: work around a potential audit memory leak
https://notcve.org/view.php?id=CVE-2024-41001
In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: work around a potential audit memory leak kmemleak complains that there's a memory leak related to connect handling: unreferenced object 0xffff0001093bdf00 (size 128): comm "iou-sqp-455", pid 457, jiffies 4294894164 hex dump (first 32 bytes): 02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 2e481b1a): [<00000000c0a26af4>] kmemleak_alloc+0x30/0x38 [<000000009c30bb45>] kmalloc_trace+0x228/0x358 [<000000009da9d39f>] __audit_sockaddr+0xd0/0x138 [<0000000089a93e34>] move_addr_to_kernel+0x1a0/0x1f8 [<000000000b4e80e6>] io_connect_prep+0x1ec/0x2d4 [<00000000abfbcd99>] io_submit_sqes+0x588/0x1e48 [<00000000e7c25e07>] io_sq_thread+0x8a4/0x10e4 [<00000000d999b491>] ret_from_fork+0x10/0x20 which can can happen if: 1) The command type does something on the prep side that triggers an audit call. 2) The thread hasn't done any operations before this that triggered an audit call inside ->issue(), where we have audit_uring_entry() and audit_uring_exit(). Work around this by issuing a blanket NOP operation before the SQPOLL does anything. • https://git.kernel.org/stable/c/55c22375cbaa24f77dd13f9ae0642915444a1227 https://git.kernel.org/stable/c/9e810bd995823786ea30543e480e8a573e5e5667 https://git.kernel.org/stable/c/a40e90d9304629002fb17200f7779823a81191d3 https://git.kernel.org/stable/c/c4ce0ab27646f4206a9eb502d6fe45cb080e1cae https://access.redhat.com/security/cve/CVE-2024-41001 https://bugzilla.redhat.com/show_bug.cgi?id=2297585 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-41000 – block/ioctl: prefer different overflow check
https://notcve.org/view.php?id=CVE-2024-41000
In the Linux kernel, the following vulnerability has been resolved: block/ioctl: prefer different overflow check Running syzkaller with the newly reintroduced signed integer overflow sanitizer shows this report: [ 62.982337] ------------[ cut here ]------------ [ 62.985692] cgroup: Invalid name [ 62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46 [ 62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1 [ 62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long' [ 62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1 [ 62.999369] random: crng reseeded on system resumption [ 63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000) [ 63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1 [ 63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 63.000682] Call Trace: [ 63.000686] <TASK> [ 63.000731] dump_stack_lvl+0x93/0xd0 [ 63.000919] __get_user_pages+0x903/0xd30 [ 63.001030] __gup_longterm_locked+0x153e/0x1ba0 [ 63.001041] ? _raw_read_unlock_irqrestore+0x17/0x50 [ 63.001072] ? try_get_folio+0x29c/0x2d0 [ 63.001083] internal_get_user_pages_fast+0x1119/0x1530 [ 63.001109] iov_iter_extract_pages+0x23b/0x580 [ 63.001206] bio_iov_iter_get_pages+0x4de/0x1220 [ 63.001235] iomap_dio_bio_iter+0x9b6/0x1410 [ 63.001297] __iomap_dio_rw+0xab4/0x1810 [ 63.001316] iomap_dio_rw+0x45/0xa0 [ 63.001328] ext4_file_write_iter+0xdde/0x1390 [ 63.001372] vfs_write+0x599/0xbd0 [ 63.001394] ksys_write+0xc8/0x190 [ 63.001403] do_syscall_64+0xd4/0x1b0 [ 63.001421] ? arch_exit_to_user_mode_prepare+0x3a/0x60 [ 63.001479] entry_SYSCALL_64_after_hwframe+0x6f/0x77 [ 63.001535] RIP: 0033:0x7f7fd3ebf539 [ 63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 [ 63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539 [ 63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004 [ 63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000 [ 63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8 ... [ 63.018142] ---[ end trace ]--- Historically, the signed integer overflow sanitizer did not work in the kernel due to its interaction with `-fwrapv` but this has since been changed [1] in the newest version of Clang; It was re-enabled in the kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow sanitizer"). Let's rework this overflow checking logic to not actually perform an overflow during the check itself, thus avoiding the UBSAN splat. [1]: https://github.com/llvm/llvm-project/pull/82432 • https://git.kernel.org/stable/c/58706e482bf45c4db48b0c53aba2468c97adda24 https://git.kernel.org/stable/c/3220c90f4dbdc6d20d0608b164d964434a810d66 https://git.kernel.org/stable/c/61ec76ec930709b7bcd69029ef1fe90491f20cf9 https://git.kernel.org/stable/c/fd841ee01fb4a79cb7f5cc424b5c96c3a73b2d1e https://git.kernel.org/stable/c/54160fb1db2de367485f21e30196c42f7ee0be4e https://git.kernel.org/stable/c/ccb326b5f9e623eb7f130fbbf2505ec0e2dcaff9 •