CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26801 – Bluetooth: Avoid potential use-after-free in hci_error_reset
https://notcve.org/view.php?id=CVE-2024-26801
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Avoid potential use-after-free in hci_error_reset While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: evite el posible use-after-free en hci_error_reset Mientras se maneja el evento HCI_EV_HARDWARE_ERROR, si el controlador BT subyacente no responde, el mecanismo de reinicio de GPIO liberaría hci_dev y provocaría un error. use-after-free en hci_error_reset. • https://git.kernel.org/stable/c/c7741d16a57cbf97eebe53f27e8216b1ff20e20c https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03 https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090 https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2 https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14 https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1 https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26798 – fbcon: always restore the old font data in fbcon_do_set_font()
https://notcve.org/view.php?id=CVE-2024-26798
In the Linux kernel, the following vulnerability has been resolved: fbcon: always restore the old font data in fbcon_do_set_font() Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vc_resize() failed) started restoring old font data upon failure (of vc_resize()). But it performs so only for user fonts. It means that the "system"/internal fonts are not restored at all. So in result, the very first call to fbcon_do_set_font() performs no restore at all upon failing vc_resize(). This can be reproduced by Syzkaller to crash the system on the next invocation of font_get(). It's rather hard to hit the allocation failure in vc_resize() on the first font_set(), but not impossible. • https://git.kernel.org/stable/c/ebd6f886aa2447fcfcdce5450c9e1028e1d681bb https://git.kernel.org/stable/c/a5a923038d70d2d4a86cb4e3f32625a5ee6e7e24 https://git.kernel.org/stable/c/f08ccb792d3eaf1dc62d8cbf6a30d6522329f660 https://git.kernel.org/stable/c/20a4b5214f7bee13c897477168c77bbf79683c3d https://git.kernel.org/stable/c/2f91a96b892fab2f2543b4a55740c5bee36b1a6b https://git.kernel.org/stable/c/73a6bd68a1342f3a44cac9dffad81ad6a003e520 https://git.kernel.org/stable/c/a2c881413dcc5d801bdc9535e51270cc88cb9cd8 https://git.kernel.org/stable/c/00d6a284fcf3fad1b7e1b5bc3cd87cbfb •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26795 – riscv: Sparse-Memory/vmemmap out-of-bounds fix
https://notcve.org/view.php?id=CVE-2024-26795
In the Linux kernel, the following vulnerability has been resolved: riscv: Sparse-Memory/vmemmap out-of-bounds fix Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap’s bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex's comments En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: Sparse-Memory/vmemmap fuera de los límites corrige Offset vmemmap para que la primera página de vmemmap se asigne a la primera página de la memoria física para garantizar que vmemmap Los límites se respetarán durante las operaciones pfn_to_page()/page_to_pfn(). Las macros de conversión producirán direcciones SV39/48/57 correctas para cada DRAM_BASE posible/válida dentro de los límites de la memoria física. v2: Abordar los comentarios de Alex • https://git.kernel.org/stable/c/d95f1a542c3df396137afa217ef9bd39cb8931ca https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26793 – gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
https://notcve.org/view.php?id=CVE-2024-26793
In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? • https://git.kernel.org/stable/c/459aa660eb1d8ce67080da1983bb81d716aa5a69 https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6 https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69 https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16 https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627 https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26792 – btrfs: fix double free of anonymous device after snapshot creation failure
https://notcve.org/view.php?id=CVE-2024-26792
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of anonymous device after snapshot creation failure When creating a snapshot we may do a double free of an anonymous device in case there's an error committing the transaction. The second free may result in freeing an anonymous device number that was allocated by some other subsystem in the kernel or another btrfs filesystem. The steps that lead to this: 1) At ioctl.c:create_snapshot() we allocate an anonymous device number and assign it to pending_snapshot->anon_dev; 2) Then we call btrfs_commit_transaction() and end up at transaction.c:create_pending_snapshot(); 3) There we call btrfs_get_new_fs_root() and pass it the anonymous device number stored in pending_snapshot->anon_dev; 4) btrfs_get_new_fs_root() frees that anonymous device number because btrfs_lookup_fs_root() returned a root - someone else did a lookup of the new root already, which could some task doing backref walking; 5) After that some error happens in the transaction commit path, and at ioctl.c:create_snapshot() we jump to the 'fail' label, and after that we free again the same anonymous device number, which in the meanwhile may have been reallocated somewhere else, because pending_snapshot->anon_dev still has the same value as in step 1. Recently syzbot ran into this and reported the following trace: ------------[ cut here ]------------ ida_free called for id=51 which is not allocated. WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525 Modules linked in: CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525 Code: 10 42 80 3c 28 (...) RSP: 0018:ffffc90015a67300 EFLAGS: 00010246 RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000 RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4 R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246 R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246 FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0 Call Trace: <TASK> btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346 create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931 btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404 create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848 btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306 btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393 btrfs_ioctl+0xa74/0xd40 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fca3e67dda9 Code: 28 00 00 00 (...) RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9 RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658 </TASK> Where we get an explicit message where we attempt to free an anonymous device number that is not currently allocated. It happens in a different code path from the example below, at btrfs_get_root_ref(), so this change may not fix the case triggered by sy ---truncated--- En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la doble liberación de un dispositivo anónimo después de un error en la creación de la instantánea. Al crear una instantánea podemos hacer una doble liberación de un dispositivo anónimo en caso de que haya un error al realizar la transacción. La segunda liberación puede resultar en la liberación de un número de dispositivo anónimo asignado por algún otro subSYSTEM en el kernel u otro SYSTEM de archivos btrfs. • https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d https://git.kernel.org/stable/c/833775656d447c545133a744a0ed1e189ce61430 https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468 https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f https://git.kernel.org/stable/c/e31546b0f34af21738c4ceac47d662c00ee6382f https://git.kernel.org/stable/c/c34adc20b91a8e55e048b18d63f4f4ae003ecf8f https://git.kernel.org/stable/c/eb3441093aad251418921246fc3b224fd1575701 https://git.kernel.org/stable/c/c8ab7521665bd0f8bc4a900244d1d5a70 •