CVSS: 4.1EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26659 – xhci: handle isoc Babble and Buffer Overrun events properly
https://notcve.org/view.php?id=CVE-2024-26659
In the Linux kernel, the following vulnerability has been resolved: xhci: handle isoc Babble and Buffer Overrun events properly xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message. Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: maneja correctamente los eventos isoc Babble y Buffer Overrun xHCI 4.9 prohíbe explícitamente suponer que xHC ha liberado su propiedad de un TD multi-TRB cuando informa un error en uno de los primeros TRB. • https://git.kernel.org/stable/c/696e4112e5c1ee61996198f0ebb6ca3fab55166e https://git.kernel.org/stable/c/2aa7bcfdbb46241c701811bbc0d64d7884e3346c https://git.kernel.org/stable/c/2e3ec80ea7ba58bbb210e83b5a0afefee7c171d3 https://git.kernel.org/stable/c/f5e7ffa9269a448a720e21f1ed1384d118298c97 https://git.kernel.org/stable/c/418456c0ce56209610523f21734c5612ee634134 https://git.kernel.org/stable/c/7c4650ded49e5b88929ecbbb631efb8b0838e811 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2024 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26658 – bcachefs: grab s_umount only if snapshotting
https://notcve.org/view.php?id=CVE-2024-26658
In the Linux kernel, the following vulnerability has been resolved: bcachefs: grab s_umount only if snapshotting When I was testing mongodb over bcachefs with compression, there is a lockdep warning when snapshotting mongodb data volume. $ cat test.sh prog=bcachefs $prog subvolume create /mnt/data $prog subvolume create /mnt/data/snapshots while true;do $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s) sleep 1s done $ cat /etc/mongodb.conf systemLog: destination: file logAppend: true path: /mnt/data/mongod.log storage: dbPath: /mnt/data/ lockdep reports: [ 3437.452330] ====================================================== [ 3437.452750] WARNING: possible circular locking dependency detected [ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E [ 3437.453562] ------------------------------------------------------ [ 3437.453981] bcachefs/35533 is trying to acquire lock: [ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190 [ 3437.454875] but task is already holding lock: [ 3437.455268] ffffa0a02b2b10e0 (&type->s_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.456009] which lock already depends on the new lock. [ 3437.456553] the existing dependency chain (in reverse order) is: [ 3437.457054] -> #3 (&type->s_umount_key#48){.+.+}-{3:3}: [ 3437.457507] down_read+0x3e/0x170 [ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.458206] __x64_sys_ioctl+0x93/0xd0 [ 3437.458498] do_syscall_64+0x42/0xf0 [ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.459155] -> #2 (&c->snapshot_create_lock){++++}-{3:3}: [ 3437.459615] down_read+0x3e/0x170 [ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs] [ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs] [ 3437.460686] notify_change+0x1f1/0x4a0 [ 3437.461283] do_truncate+0x7f/0xd0 [ 3437.461555] path_openat+0xa57/0xce0 [ 3437.461836] do_filp_open+0xb4/0x160 [ 3437.462116] do_sys_openat2+0x91/0xc0 [ 3437.462402] __x64_sys_openat+0x53/0xa0 [ 3437.462701] do_syscall_64+0x42/0xf0 [ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.463359] -> #1 (&sb->s_type->i_mutex_key#15){+.+.}-{3:3}: [ 3437.463843] down_write+0x3b/0xc0 [ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs] [ 3437.464493] vfs_write+0x21b/0x4c0 [ 3437.464653] ksys_write+0x69/0xf0 [ 3437.464839] do_syscall_64+0x42/0xf0 [ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.465231] -> #0 (sb_writers#10){.+.+}-{0:0}: [ 3437.465471] __lock_acquire+0x1455/0x21b0 [ 3437.465656] lock_acquire+0xc6/0x2b0 [ 3437.465822] mnt_want_write+0x46/0x1a0 [ 3437.465996] filename_create+0x62/0x190 [ 3437.466175] user_path_create+0x2d/0x50 [ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs] [ 3437.466617] __x64_sys_ioctl+0x93/0xd0 [ 3437.466791] do_syscall_64+0x42/0xf0 [ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.467180] other info that might help us debug this: [ 3437.469670] 2 locks held by bcachefs/35533: other info that might help us debug this: [ 3437.467507] Chain exists of: sb_writers#10 --> &c->snapshot_create_lock --> &type->s_umount_key#48 [ 3437.467979] Possible unsafe locking scenario: [ 3437.468223] CPU0 CPU1 [ 3437.468405] ---- ---- [ 3437.468585] rlock(&type->s_umount_key#48); [ 3437.468758] lock(&c->snapshot_create_lock); [ 3437.469030] lock(&type->s_umount_key#48); [ 3437.469291] rlock(sb_writers#10); [ 3437.469434] *** DEADLOCK *** [ 3437.469 ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bcachefs: toma s_umount solo si se toma una instantánea Cuando estaba probando mongodb sobre bcachefs con compresión, hay una advertencia de lockdep al tomar una instantánea del volumen de datos de mongodb. $ cat test.sh prog=bcachefs $prog subvolumen crear /mnt/data $prog subvolumen crear /mnt/data/snapshots mientras es verdadero;do $prog subvolumen snapshot /mnt/data /mnt/data/snapshots/$(fecha +% s) dormir 1 hecho $ cat /etc/mongodb.conf systemLog: destino: archivo logAppend: verdadera ruta: /mnt/data/mongod.log almacenamiento: dbPath: /mnt/data/ lockdep informes: [3437.452330] ==== ==================================================== [ 3437.452750] ADVERTENCIA: posible dependencia de bloqueo circular detectada [ 3437.453168] 6.7.0-rc7-custom+ #85 Contaminado: GE [ 3437.453562] ---------------------- -------------------------------- [ 3437.453981] bcachefs/35533 está intentando adquirir el bloqueo: [ 3437.454325] ffffa0a02b2b1418 (sb_writers #10){.+.+}-{0:0}, en: filename_create+0x62/0x190 [ 3437.454875] pero la tarea ya mantiene el bloqueo: [ 3437.455268] ffffa0a02b2b10e0 (&type->s_umount_key#48){.+.+ }-{3:3}, en: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.456009] cuyo bloqueo ya depende del nuevo bloqueo. [ 3437.456553] la cadena de dependencia existente (en orden inverso) es: [ 3437.457054] -> #3 (&type->s_umount_key#48){.+.+}-{3:3}: [ 3437.457507] down_read+0x3e/0x170 [ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.458206] __x64_sys_ioctl+0x93/0xd0 [ 3437.458498] do_syscall_64+0x42/0xf0 [ 3437.458 779] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 [3437.459155] -> #2 (&c->snapshot_create_lock){+ +++}-{3:3}: [ 3437.459615] down_read+0x3e/0x170 [ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs] [ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs] [ 3437.4 60686] notificar_cambio+0x1f1/0x4a0 [ 3437.461283] do_truncate+0x7f/0xd0 [ 3437.461555] path_openat+0xa57/0xce0 [ 3437.461836] do_filp_open+0xb4/0x160 [ 3437.462116] do_sys_openat2+0x91/0xc0 [ 34 37.462402] __x64_sys_openat+0x53/0xa0 [ 3437.462701] do_syscall_64+0x42/0xf0 [ 3437.462982] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.463359] -> #1 (&sb->s_type->i_mutex_key#15){+.+.}-{3:3}: [ 3437.463843] down_write+0x3b/0xc0 [ 3437.464223] bch2_write_it e+0x5b /0xcc0 [bcachefs] [ 3437.464493] vfs_write+0x21b/0x4c0 [ 3437.464653] ksys_write+0x69/0xf0 [ 3437.464839] do_syscall_64+0x42/0xf0 [ 3437.465009] entrada_SYSCALL _64_after_hwframe+0x6e/0x76 [ 3437.465231] -> #0 (sb_writers#10){ .+.+}-{0:0}: [ 3437.465471] __lock_acquire+0x1455/0x21b0 [ 3437.465656] lock_acquire+0xc6/0x2b0 [ 3437.465822] mnt_want_write+0x46/0x1a0 [ 3437.465996] nombre de archivo _create+0x62/0x190 [ 3437.466175] ruta_usuario_create+0x2d /0x50 [ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs] [ 3437.466617] __x64_sys_ioctl+0x93/0xd0 [ 3437.466791] do_syscall_64+0x42/0xf0 [ 3437 .466957] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.467180] otra información que podría ayudarnos a depurar esto: [ 3437.469670] 2 bloqueos mantenidos por bcachefs/35533: otra información que podría ayudarnos a depurar esto: [3437.467507] Existe cadena de: sb_writers#10 --> &c->snapshot_create_lock --> &type->s_umount_key#48 [3437.467979] Posiblemente inseguro escenario de bloqueo: [3437.468223] CPU0 CPU1 [3437.468405] ---- ---- [3437.468585] rlock(&type->s_umount_key#48); [ 3437.468758] bloqueo(&c->snapshot_create_lock); [ 3437.469030] bloqueo(&type->s_umount_key#48); [3437.469291] rlock(sb_writers#10); [ 3437.469434] *** INTERBLOQUEO *** [ 3437.469 ---truncado--- • https://git.kernel.org/stable/c/5b41d3fd04c6757b9c2a60a0c5b2609cae9999df https://git.kernel.org/stable/c/2acc59dd88d27ad69b66ded80df16c042b04eeec •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52631 – fs/ntfs3: Fix an NULL dereference bug
https://notcve.org/view.php?id=CVE-2023-52631
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix an NULL dereference bug The issue here is when this is called from ntfs_load_attr_list(). The "size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow on a 64bit systems but on 32bit systems the "+ 1023" can overflow and the result is zero. This means that the kmalloc will succeed by returning the ZERO_SIZE_PTR and then the memcpy() will crash with an Oops on the next line. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fs/ntfs3: corrige un error de desreferencia NULL El problema aquí es cuando se llama desde ntfs_load_attr_list(). El "tamaño" proviene de le32_to_cpu(attr->res.data_size), por lo que no puede desbordarse en sistemas de 64 bits, pero en sistemas de 32 bits el "+ 1023" puede desbordarse y el resultado es cero. • https://git.kernel.org/stable/c/be71b5cba2e6485e8959da7a9f9a44461a1bb074 https://git.kernel.org/stable/c/ae4acad41b0f93f1c26cc0fc9135bb79d8282d0b https://git.kernel.org/stable/c/ec1bedd797588fe38fc11cba26d77bb1d9b194c6 https://git.kernel.org/stable/c/fb7bcd1722bc9bc55160378f5f99c01198fd14a7 https://git.kernel.org/stable/c/686820fe141ea0220fc6fdfc7e5694f915cf64b2 https://git.kernel.org/stable/c/b2dd7b953c25ffd5912dda17e980e7168bebcf6c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26657 – drm/sched: fix null-ptr-deref in init entity
https://notcve.org/view.php?id=CVE-2024-26657
In the Linux kernel, the following vulnerability has been resolved: drm/sched: fix null-ptr-deref in init entity The bug can be triggered by sending an amdgpu_cs_wait_ioctl to the AMDGPU DRM driver on any ASICs with valid context. The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>. For example the following code: static void Syzkaller2(int fd) { union drm_amdgpu_ctx arg1; union drm_amdgpu_wait_cs arg2; arg1.in.op = AMDGPU_CTX_OP_ALLOC_CTX; ret = drmIoctl(fd, 0x140106442 /* amdgpu_ctx_ioctl */, &arg1); arg2.in.handle = 0x0; arg2.in.timeout = 0x2000000000000; arg2.in.ip_type = AMD_IP_VPE /* 0x9 */; arg2->in.ip_instance = 0x0; arg2.in.ring = 0x0; arg2.in.ctx_id = arg1.out.alloc.ctx_id; drmIoctl(fd, 0xc0206449 /* AMDGPU_WAIT_CS * /, &arg2); } The ioctl AMDGPU_WAIT_CS without previously submitted job could be assumed that the error should be returned, but the following commit 1decbf6bb0b4dc56c9da6c5e57b994ebfc2be3aa modified the logic and allowed to have sched_rq equal to NULL. As a result when there is no job the ioctl AMDGPU_WAIT_CS returns success. The change fixes null-ptr-deref in init entity and the stack below demonstrates the error condition: [ +0.000007] BUG: kernel NULL pointer dereference, address: 0000000000000028 [ +0.007086] #PF: supervisor read access in kernel mode [ +0.005234] #PF: error_code(0x0000) - not-present page [ +0.005232] PGD 0 P4D 0 [ +0.002501] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ +0.005034] CPU: 10 PID: 9229 Comm: amd_basic Tainted: G B W L 6.7.0+ #4 [ +0.007797] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.009798] RIP: 0010:drm_sched_entity_init+0x2d3/0x420 [gpu_sched] [ +0.006426] Code: 80 00 00 00 00 00 00 00 e8 1a 81 82 e0 49 89 9c 24 c0 00 00 00 4c 89 ef e8 4a 80 82 e0 49 8b 5d 00 48 8d 7b 28 e8 3d 80 82 e0 <48> 83 7b 28 00 0f 84 28 01 00 00 4d 8d ac 24 98 00 00 00 49 8d 5c [ +0.019094] RSP: 0018:ffffc90014c1fa40 EFLAGS: 00010282 [ +0.005237] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff8113f3fa [ +0.007326] RDX: fffffbfff0a7889d RSI: 0000000000000008 RDI: ffffffff853c44e0 [ +0.007264] RBP: ffffc90014c1fa80 R08: 0000000000000001 R09: fffffbfff0a7889c [ +0.007266] R10: ffffffff853c44e7 R11: 0000000000000001 R12: ffff8881a719b010 [ +0.007263] R13: ffff88810d412748 R14: 0000000000000002 R15: 0000000000000000 [ +0.007264] FS: 00007ffff7045540(0000) GS:ffff8883cc900000(0000) knlGS:0000000000000000 [ +0.008236] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.005851] CR2: 0000000000000028 CR3: 000000011912e000 CR4: 0000000000350ef0 [ +0.007175] Call Trace: [ +0.002561] <TASK> [ +0.002141] ? show_regs+0x6a/0x80 [ +0.003473] ? __die+0x25/0x70 [ +0.003124] ? page_fault_oops+0x214/0x720 [ +0.004179] ? preempt_count_sub+0x18/0xc0 [ +0.004093] ? • https://git.kernel.org/stable/c/56e449603f0ac580700621a356d35d5716a62ce5 https://git.kernel.org/stable/c/74cd204c7afe498aa9dcc3ebf0ecac53d477a429 https://git.kernel.org/stable/c/54b5b7275dfdec35812ccce70930cd7c4ee612b2 https://git.kernel.org/stable/c/f34e8bb7d6c6626933fe993e03ed59ae85e16abb •
CVSS: 4.7EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26656 – drm/amdgpu: fix use-after-free bug
https://notcve.org/view.php?id=CVE-2024-26656
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix use-after-free bug The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl to the AMDGPU DRM driver on any ASICs with an invalid address and size. The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>. For example the following code: static void Syzkaller1(int fd) { struct drm_amdgpu_gem_userptr arg; int ret; arg.addr = 0xffffffffffff0000; arg.size = 0x80000000; /*2 Gb*/ arg.flags = 0x7; ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg); } Due to the address and size are not valid there is a failure in amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert-> check_shl_overflow, but we even the amdgpu_hmm_register failure we still call amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address. The following stack is below when the issue is reproduced when Kazan is enabled: [ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340 [ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80 [ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246 [ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b [ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260 [ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25 [ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00 [ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260 [ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000 [ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0 [ +0.000010] Call Trace: [ +0.000006] <TASK> [ +0.000007] ? show_regs+0x6a/0x80 [ +0.000018] ? __warn+0xa5/0x1b0 [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340 [ +0.000018] ? report_bug+0x24a/0x290 [ +0.000022] ? • https://git.kernel.org/stable/c/e87e08c94c9541b4e18c4c13f2f605935f512605 https://git.kernel.org/stable/c/af054a5fb24a144f99895afce9519d709891894c https://git.kernel.org/stable/c/22f665ecfd1225afa1309ace623157d12bb9bb0c https://git.kernel.org/stable/c/22207fd5c80177b860279653d017474b2812af5e https://access.redhat.com/security/cve/CVE-2024-26656 https://bugzilla.redhat.com/show_bug.cgi?id=2272692 • CWE-416: Use After Free •