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: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48832 – audit: don't deref the syscall args when checking the openat2 open_how::flags
https://notcve.org/view.php?id=CVE-2022-48832
In the Linux kernel, the following vulnerability has been resolved: audit: don't deref the syscall args when checking the openat2 open_how::flags As reported by Jeff, dereferencing the openat2 syscall argument in audit_match_perm() to obtain the open_how::flags can result in an oops/page-fault. This patch fixes this by using the open_how struct that we store in the audit_context with audit_openat2_how(). Independent of this patch, Richard Guy Briggs posted a similar patch to the audit mailing list roughly 40 minutes after this patch was posted. • https://git.kernel.org/stable/c/1c30e3af8a79260cdba833a719209b01e6b92300 https://git.kernel.org/stable/c/310c9ddfdf1f8d3c9834f02175eae79c8b254b6c https://git.kernel.org/stable/c/7a82f89de92aac5a244d3735b2bd162c1147620c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48831 – ima: fix reference leak in asymmetric_verify()
https://notcve.org/view.php?id=CVE-2022-48831
In the Linux kernel, the following vulnerability has been resolved: ima: fix reference leak in asymmetric_verify() Don't leak a reference to the key if its algorithm is unknown. • https://git.kernel.org/stable/c/947d70597236dd5ae65c1f68c8eabfb962ee5a6b https://git.kernel.org/stable/c/0838d6d68182f0b28a5434bc6d50727c4757e35b https://git.kernel.org/stable/c/89f586d3398f4cc0432ed870949dffb702940754 https://git.kernel.org/stable/c/926fd9f23b27ca6587492c3f58f4c7f4cd01dad5 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48830 – can: isotp: fix potential CAN frame reception race in isotp_rcv()
https://notcve.org/view.php?id=CVE-2022-48830
In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix potential CAN frame reception race in isotp_rcv() When receiving a CAN frame the current code logic does not consider concurrently receiving processes which do not show up in real world usage. Ziyang Xuan writes: The following syz problem is one of the scenarios. so->rx.len is changed by isotp_rcv_ff() during isotp_rcv_cf(), so->rx.len equals 0 before alloc_skb() and equals 4096 after alloc_skb(). That will trigger skb_over_panic() in skb_put(). ======================================================= CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0 RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113 Call Trace: <TASK> skb_over_panic net/core/skbuff.c:118 [inline] skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 isotp_rcv_cf net/can/isotp.c:570 [inline] isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 deliver net/can/af_can.c:574 [inline] can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 can_receive+0x31d/0x580 net/can/af_can.c:665 can_rcv+0x120/0x1c0 net/can/af_can.c:696 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465 __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579 Therefore we make sure the state changes and data structures stay consistent at CAN frame reception time by adding a spin_lock in isotp_rcv(). This fixes the issue reported by syzkaller but does not affect real world operation. • https://git.kernel.org/stable/c/e057dd3fc20ffb3d7f150af46542a51b59b90127 https://git.kernel.org/stable/c/7b53d2204ce79b27a878074a77d64f40ec21dbca https://git.kernel.org/stable/c/f90cc68f9f4b5d8585ad5d0a206a9d37ac299ef3 https://git.kernel.org/stable/c/5b068f33bc8acfcfd5ea7992a2dafb30d89bad30 https://git.kernel.org/stable/c/7c759040c1dd03954f650f147ae7175476d51314 •