CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46745 – Input: uinput - reject requests with unreasonable number of slots
https://notcve.org/view.php?id=CVE-2024-46745
In the Linux kernel, the following vulnerability has been resolved: Input: uinput - reject requests with unreasonable number of slots When exercising uinput interface syzkaller may try setting up device with a really large number of slots, which causes memory allocation failure in input_mt_init_slots(). While this allocation failure is handled properly and request is rejected, it results in syzkaller reports. Additionally, such request may put undue burden on the system which will try to free a lot of memory for a bogus request. Fix it by limiting allowed number of slots to 100. This can easily be extended if we see devices that can track more than 100 contacts. • https://git.kernel.org/stable/c/9c6d189f0c1c59ba9a32326ec82a0b367a3cd47b https://git.kernel.org/stable/c/597ff930296c4c8fc6b6a536884d4f1a7187ec70 https://git.kernel.org/stable/c/51fa08edd80003db700bdaa099385c5900d27f4b https://git.kernel.org/stable/c/9719687398dea8a6a12a10321a54dd75eec7ab2d https://git.kernel.org/stable/c/61df76619e270a46fd427fbdeb670ad491c42de2 https://git.kernel.org/stable/c/a4858b00a1ec57043697fb935565fe267f161833 https://git.kernel.org/stable/c/d76fc0f0b18d49b7e721c9e4975ef4bffde2f3e7 https://git.kernel.org/stable/c/206f533a0a7c683982af473079c4111f4 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46744 – Squashfs: sanity check symbolic link size
https://notcve.org/view.php?id=CVE-2024-46744
In the Linux kernel, the following vulnerability has been resolved: Squashfs: sanity check symbolic link size Syzkiller reports a "KMSAN: uninit-value in pick_link" bug. This is caused by an uninitialised page, which is ultimately caused by a corrupted symbolic link size read from disk. The reason why the corrupted symlink size causes an uninitialised page is due to the following sequence of events: 1. squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size. 2. Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number. 3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page. This patch adds a sanity check which checks that the symbolic link size is not larger than expected. -- V2: fix spelling mistake. • https://git.kernel.org/stable/c/f82cb7f24032ed023fc67d26ea9bf322d8431a90 https://git.kernel.org/stable/c/1b9451ba6f21478a75288ea3e3fca4be35e2a438 https://git.kernel.org/stable/c/5c8906de98d0d7ad42ff3edf2cb6cd7e0ea658c4 https://git.kernel.org/stable/c/087f25b2d36adae19951114ffcbb7106ed405ebb https://git.kernel.org/stable/c/fac5e82ab1334fc8ed6ff7183702df634bd1d93d https://git.kernel.org/stable/c/c3af7e460a526007e4bed1ce3623274a1a6afe5e https://git.kernel.org/stable/c/ef4e249971eb77ec33d74c5c3de1e2576faf6c90 https://git.kernel.org/stable/c/810ee43d9cd245d138a2733d87a24858a •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46743 – of/irq: Prevent device address out-of-bounds read in interrupt map walk
https://notcve.org/view.php?id=CVE-2024-46743
In the Linux kernel, the following vulnerability has been resolved: of/irq: Prevent device address out-of-bounds read in interrupt map walk When of_irq_parse_raw() is invoked with a device address smaller than the interrupt parent node (from #address-cells property), KASAN detects the following out-of-bounds read when populating the initial match table (dyndbg="func of_irq_parse_* +p"): OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0 OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2 OF: intspec=4 OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2 OF: -> addrsize=3 ================================================================== BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0 Read of size 4 at addr ffffff81beca5608 by task bash/764 CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023 Call trace: dump_backtrace+0xdc/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0x6c/0x84 print_report+0x150/0x448 kasan_report+0x98/0x140 __asan_load4+0x78/0xa0 of_irq_parse_raw+0x2b8/0x8d0 of_irq_parse_one+0x24c/0x270 parse_interrupts+0xc0/0x120 of_fwnode_add_links+0x100/0x2d0 fw_devlink_parse_fwtree+0x64/0xc0 device_add+0xb38/0xc30 of_device_add+0x64/0x90 of_platform_device_create_pdata+0xd0/0x170 of_platform_bus_create+0x244/0x600 of_platform_notify+0x1b0/0x254 blocking_notifier_call_chain+0x9c/0xd0 __of_changeset_entry_notify+0x1b8/0x230 __of_changeset_apply_notify+0x54/0xe4 of_overlay_fdt_apply+0xc04/0xd94 ... The buggy address belongs to the object at ffffff81beca5600 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffffff81beca5600, ffffff81beca5680) The buggy address belongs to the physical page: page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4 head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0 flags: 0x8000000000010200(slab|head|zone=2) raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ================================================================== OF: -> got it ! Prevent the out-of-bounds read by copying the device address into a buffer of sufficient size. • https://git.kernel.org/stable/c/d2a79494d8a5262949736fb2c3ac44d20a51b0d8 https://git.kernel.org/stable/c/defcaa426ba0bc89ffdafb799d2e50b52f74ffc4 https://git.kernel.org/stable/c/9d1e9f0876b03d74d44513a0ed3ed15ef8f2fed5 https://git.kernel.org/stable/c/baaf26723beab3a04da578d3008be3544f83758f https://git.kernel.org/stable/c/8ff351ea12e918db1373b915c4c268815929cbe5 https://git.kernel.org/stable/c/7ead730af11ee7da107f16fc77995613c58d292d https://git.kernel.org/stable/c/bf68acd840b6a5bfd3777e0d5aaa204db6b461a9 https://git.kernel.org/stable/c/b739dffa5d570b411d4bdf4bb9b8dfd6b •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46738 – VMCI: Fix use-after-free when removing resource in vmci_resource_remove()
https://notcve.org/view.php?id=CVE-2024-46738
In the Linux kernel, the following vulnerability has been resolved: VMCI: Fix use-after-free when removing resource in vmci_resource_remove() When removing a resource from vmci_resource_table in vmci_resource_remove(), the search is performed using the resource handle by comparing context and resource fields. It is possible though to create two resources with different types but same handle (same context and resource fields). When trying to remove one of the resources, vmci_resource_remove() may not remove the intended one, but the object will still be freed as in the case of the datagram type in vmci_datagram_destroy_handle(). vmci_resource_table will still hold a pointer to this freed resource leading to a use-after-free vulnerability. BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0 This change ensures the type is also checked when removing the resource from vmci_resource_table in vmci_resource_remove(). • https://git.kernel.org/stable/c/bc63dedb7d46a7d690c6b6edf69136b88af06cc6 https://git.kernel.org/stable/c/f6365931bf7c07b2b397dbb06a4f6573cc9fae73 https://git.kernel.org/stable/c/b243d52b5f6f59f9d39e69b191fb3d58b94a43b1 https://git.kernel.org/stable/c/6c563a29857aa8053b67ee141191f69757f27f6e https://git.kernel.org/stable/c/ef5f4d0c5ee22d4f873116fec844ff6edaf3fa7d https://git.kernel.org/stable/c/b9efdf333174468651be40390cbc79c9f55d9cce https://git.kernel.org/stable/c/39e7e593418ccdbd151f2925fa6be1a616d16c96 https://git.kernel.org/stable/c/00fe5292f081f8d773e572df8e03bf6e1 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46733 – btrfs: fix qgroup reserve leaks in cow_file_range
https://notcve.org/view.php?id=CVE-2024-46733
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix qgroup reserve leaks in cow_file_range In the buffered write path, the dirty page owns the qgroup reserve until it creates an ordered_extent. Therefore, any errors that occur before the ordered_extent is created must free that reservation, or else the space is leaked. The fstest generic/475 exercises various IO error paths, and is able to trigger errors in cow_file_range where we fail to get to allocating the ordered extent. Note that because we *do* clear delalloc, we are likely to remove the inode from the delalloc list, so the inodes/pages to not have invalidate/launder called on them in the commit abort path. This results in failures at the unmount stage of the test that look like: BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: <TASK> ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? • https://git.kernel.org/stable/c/e42ef22bc10f0309c0c65d8d6ca8b4127a674b7f https://git.kernel.org/stable/c/30479f31d44d47ed00ae0c7453d9b253537005b2 •