CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48839 – net/packet: fix slab-out-of-bounds access in packet_recvmsg()
https://notcve.org/view.php?id=CVE-2022-48839
In the Linux kernel, the following vulnerability has been resolved: net/packet: fix slab-out-of-bounds access in packet_recvmsg() syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH and mmap operations, tpacket_rcv() is queueing skbs with garbage in skb->cb[], triggering a too big copy [1] Presumably, users of af_packet using mmap() already gets correct metadata from the mapped buffer, we can simply make sure to clear 12 bytes that might be copied to user space later. BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline] BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489 Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631 CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 memcpy+0x39/0x60 mm/kasan/shadow.c:66 memcpy include/linux/fortify-string.h:225 [inline] packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fdfd5954c29 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005 RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60 R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54 </TASK> addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame: ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246 this frame has 1 object: [32, 160) 'addr' Memory state around the buggy address: ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 >ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 ^ ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00 ================================================================== En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/packet: corrige el acceso slab-out-of-bounds en paquete_recvmsg() syzbot descubrió que cuando un socket AF_PACKET utiliza operaciones PACKET_COPY_THRESH y mmap, tpacket_rcv() está poniendo en cola skbs con basura en skb->cb[], lo que desencadena una copia demasiado grande [1] Presumiblemente, los usuarios de af_packet que usan mmap() ya obtienen los metadatos correctos del búfer asignado, simplemente podemos asegurarnos de borrar 12 bytes que podrían copiarse al usuario espacio más tarde. ERROR: KASAN: pila fuera de los límites en memcpy include/linux/fortify-string.h:225 [en línea] ERROR: KASAN: pila fuera de los límites en paquete_recvmsg+0x56c/0x1150 net/packet/af_packet. c:3489 Escritura de tamaño 165 en la dirección ffffc9000385fb78 por tarea syz-executor233/3631 CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0 Nombre de hardware: Google Google Compute Engine /Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf /0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [en línea] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 memcpy+0x39/0x60 mm/kasan/shadow.c:66 memcpy include/linux/fortify-string.h:225 [en línea] paquete_recvmsg+0x56c/ 0x1150 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:948 [en línea] sock_recvmsg net/socket.c:966 [en línea] sock_recvmsg net/socket.c:962 [en línea] ____sys_recvmsg+0x2c4/0x600 net/ socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] arco xb0 /x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fdfd5954c29 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcf8e71e48 EFLAGS: 0000246 ORIG_RAX: 000000000000002f RAX : ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 000000000000005 RBP: 0000000 000000000 R08: 000000000000000d R09: 000000000000000d R10: 0000000000000000 R11: 00000000000000246 R12: 00007ffcf8e71e60 R13: 0000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54 dirección ffffc9000385fb78 está ubicado en la pila de la tarea syz-executor233/3631 en el desplazamiento 32 en el marco: ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246 este marco tiene 1 objeto: [32, 160) 'addr' Estado de memoria alrededor del buggy dirección: ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 c9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 ^ ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 0 0 00 00 00 00 ====== ==================================================== ========== • https://git.kernel.org/stable/c/0fb375fb9b93b7d822debc6a734052337ccfdb1f https://git.kernel.org/stable/c/b9d5772d60f8e7ef34e290f72fc20e3a4883e7d0 https://git.kernel.org/stable/c/b1e27cda1e3c12b705875bb7e247a97168580e33 https://git.kernel.org/stable/c/a33dd1e6693f80d805155b3f69c18c2f642915da https://git.kernel.org/stable/c/268dcf1f7b3193bc446ec3d14e08a240e9561e4d https://git.kernel.org/stable/c/70b7b3c055fd4a464da8da55ff4c1f84269f9b02 https://git.kernel.org/stable/c/a055f5f2841f7522b44a2b1eccb1951b4b03d51a https://git.kernel.org/stable/c/ef591b35176029fdefea38e8388ffa371 • CWE-125: Out-of-bounds Read •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48834 – usb: usbtmc: Fix bug in pipe direction for control transfers
https://notcve.org/view.php?id=CVE-2022-48834
In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Fix bug in pipe direction for control transfers The syzbot fuzzer reported a minor bug in the usbtmc driver: usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0 WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Modules linked in: CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [inline] The problem is that usbtmc_ioctl_request() uses usb_rcvctrlpipe() for all of its transfers, whether they are in or out. It's easy to fix. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: usbtmc: corrige un error en la dirección de la tubería para las transferencias de control. El syzbot fuzzer informó un error menor en el controlador usbtmc: usb 5-1: directorio de control BOGUS, la tubería 80001e80 no coincide con bRequestType 0 ADVERTENCIA: CPU: 0 PID: 3813 en drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Módulos vinculados en: CPU: 0 PID: 3813 Comm : syz-executor122 No contaminado 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Seguimiento de llamadas: usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core /message.c:102 [en línea] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [en línea] El problema es que usbtmc_ioctl_request() usa usb_rcvctrlpipe( ) para todas sus transferencias, ya sean de entrada o de salida. • https://git.kernel.org/stable/c/700a0715854c1e79a73341724ce4f5bb01abc016 https://git.kernel.org/stable/c/10a805334a11acd547602d6c4cf540a0f6ab5c6e https://git.kernel.org/stable/c/c69aef9db878ab277068a8cc1b4bf0cf309dc2b7 https://git.kernel.org/stable/c/5f6a2d63c68c12cf61259df7c3527a0e05dce952 https://git.kernel.org/stable/c/e9b667a82cdcfe21d590344447d65daed52b353b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48833 – btrfs: skip reserved bytes warning on unmount after log cleanup failure
https://notcve.org/view.php?id=CVE-2022-48833
In the Linux kernel, the following vulnerability has been resolved: btrfs: skip reserved bytes warning on unmount after log cleanup failure After the recent changes made by commit c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it") and its followup fix, commit 651740a5024117 ("btrfs: check WRITE_ERR when trying to read an extent buffer"), we can now end up not cleaning up space reservations of log tree extent buffers after a transaction abort happens, as well as not cleaning up still dirty extent buffers. This happens because if writeback for a log tree extent buffer failed, then we have cleared the bit EXTENT_BUFFER_UPTODATE from the extent buffer and we have also set the bit EXTENT_BUFFER_WRITE_ERR on it. Later on, when trying to free the log tree with free_log_tree(), which iterates over the tree, we can end up getting an -EIO error when trying to read a node or a leaf, since read_extent_buffer_pages() returns -EIO if an extent buffer does not have EXTENT_BUFFER_UPTODATE set and has the EXTENT_BUFFER_WRITE_ERR bit set. Getting that -EIO means that we return immediately as we can not iterate over the entire tree. In that case we never update the reserved space for an extent buffer in the respective block group and space_info object. When this happens we get the following traces when unmounting the fs: [174957.284509] BTRFS: error (device dm-0) in cleanup_transaction:1913: errno=-5 IO failure [174957.286497] BTRFS: error (device dm-0) in free_log_tree:3420: errno=-5 IO failure [174957.399379] ------------[ cut here ]------------ [174957.402497] WARNING: CPU: 2 PID: 3206883 at fs/btrfs/block-group.c:127 btrfs_put_block_group+0x77/0xb0 [btrfs] [174957.407523] Modules linked in: btrfs overlay dm_zero (...) [174957.424917] CPU: 2 PID: 3206883 Comm: umount Tainted: G W 5.16.0-rc5-btrfs-next-109 #1 [174957.426689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [174957.428716] RIP: 0010:btrfs_put_block_group+0x77/0xb0 [btrfs] [174957.429717] Code: 21 48 8b bd (...) [174957.432867] RSP: 0018:ffffb70d41cffdd0 EFLAGS: 00010206 [174957.433632] RAX: 0000000000000001 RBX: ffff8b09c3848000 RCX: ffff8b0758edd1c8 [174957.434689] RDX: 0000000000000001 RSI: ffffffffc0b467e7 RDI: ffff8b0758edd000 [174957.436068] RBP: ffff8b0758edd000 R08: 0000000000000000 R09: 0000000000000000 [174957.437114] R10: 0000000000000246 R11: 0000000000000000 R12: ffff8b09c3848148 [174957.438140] R13: ffff8b09c3848198 R14: ffff8b0758edd188 R15: dead000000000100 [174957.439317] FS: 00007f328fb82800(0000) GS:ffff8b0a2d200000(0000) knlGS:0000000000000000 [174957.440402] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [174957.441164] CR2: 00007fff13563e98 CR3: 0000000404f4e005 CR4: 0000000000370ee0 [174957.442117] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [174957.443076] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [174957.443948] Call Trace: [174957.444264] <TASK> [174957.444538] btrfs_free_block_groups+0x255/0x3c0 [btrfs] [174957.445238] close_ctree+0x301/0x357 [btrfs] [174957.445803] ? call_rcu+0x16c/0x290 [174957.446250] generic_shutdown_super+0x74/0x120 [174957.446832] kill_anon_super+0x14/0x30 [174957.447305] btrfs_kill_super+0x12/0x20 [btrfs] [174957.447890] deactivate_locked_super+0x31/0xa0 [174957.448440] cleanup_mnt+0x147/0x1c0 [174957.448888] task_work_run+0x5c/0xa0 [174957.449336] exit_to_user_mode_prepare+0x1e5/0x1f0 [174957.449934] syscall_exit_to_user_mode+0x16/0x40 [174957.450512] do_syscall_64+0x48/0xc0 [174957.450980] entry_SYSCALL_64_after_hwframe+0x44/0xae [174957.451605] RIP: 0033:0x7f328fdc4a97 [174957.452059] Code: 03 0c 00 f7 (...) [174957.454320] RSP: 002b:00007fff13564ec8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [174957.455262] RAX: 0000000000000000 RBX: 00007f328feea264 RCX: 00007f328fdc4a97 [174957.456131] RDX: 0000000000000000 RSI: 00000000000000 ---truncated--- • https://git.kernel.org/stable/c/4c5d94990fa2fd609360ecd0f7e183212a7d115c https://git.kernel.org/stable/c/44557a8f539a822c91238c1f95a95f98a5093d82 https://git.kernel.org/stable/c/40cdc509877bacb438213b83c7541c5e24a1d9ec •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48829 – NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes
https://notcve.org/view.php?id=CVE-2022-48829
In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes iattr::ia_size is a loff_t, so these NFSv3 procedures must be careful to deal with incoming client size values that are larger than s64_max without corrupting the value. Silently capping the value results in storing a different value than the client passed in which is unexpected behavior, so remove the min_t() check in decode_sattr3(). Note that RFC 1813 permits only the WRITE procedure to return NFS3ERR_FBIG. We believe that NFSv3 reference implementations also return NFS3ERR_FBIG when ia_size is too large. • https://git.kernel.org/stable/c/a231ae6bb50e7c0a9e9efd7b0d10687f1d71b3a3 https://git.kernel.org/stable/c/37f2d2cd8eadddbbd9c7bda327a9393399b2f89b https://git.kernel.org/stable/c/aa9051ddb4b378bd22e72a67bc77b9fc1482c5f0 https://git.kernel.org/stable/c/a648fdeb7c0e17177a2280344d015dba3fbe3314 https://access.redhat.com/security/cve/CVE-2022-48829 https://bugzilla.redhat.com/show_bug.cgi?id=2298168 • CWE-253: Incorrect Check of Function Return Value •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48828 – NFSD: Fix ia_size underflow
https://notcve.org/view.php?id=CVE-2022-48828
In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix ia_size underflow iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and NFSv4 both define file size as an unsigned 64-bit type. Thus there is a range of valid file size values an NFS client can send that is already larger than Linux can handle. Currently decode_fattr4() dumps a full u64 value into ia_size. If that value happens to be larger than S64_MAX, then ia_size underflows. I'm about to fix up the NFSv3 behavior as well, so let's catch the underflow in the common code path: nfsd_setattr(). • https://git.kernel.org/stable/c/38d02ba22e43b6fc7d291cf724bc6e3b7be6626b https://git.kernel.org/stable/c/8e0ecaf7a7e57b30284d6b3289cc436100fadc48 https://git.kernel.org/stable/c/da22ca1ad548429d7822011c54cfe210718e0aa7 https://git.kernel.org/stable/c/e6faac3f58c7c4176b66f63def17a34232a17b0e https://access.redhat.com/security/cve/CVE-2022-48828 https://bugzilla.redhat.com/show_bug.cgi?id=2298167 •