Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/packet: fix slab-out-of-bounds access in packet_recvmsg()<br /> <br /> syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH<br /> and mmap operations, tpacket_rcv() is queueing skbs with<br /> garbage in skb-&gt;cb[], triggering a too big copy [1]<br /> <br /> Presumably, users of af_packet using mmap() already gets correct<br /> metadata from the mapped buffer, we can simply make sure<br /> to clear 12 bytes that might be copied to user space later.<br /> <br /> BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]<br /> BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489<br /> Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631<br /> <br /> CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255<br /> __kasan_report mm/kasan/report.c:442 [inline]<br /> kasan_report.cold+0x83/0xdf mm/kasan/report.c:459<br /> check_region_inline mm/kasan/generic.c:183 [inline]<br /> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189<br /> memcpy+0x39/0x60 mm/kasan/shadow.c:66<br /> memcpy include/linux/fortify-string.h:225 [inline]<br /> packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489<br /> sock_recvmsg_nosec net/socket.c:948 [inline]<br /> sock_recvmsg net/socket.c:966 [inline]<br /> sock_recvmsg net/socket.c:962 [inline]<br /> ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632<br /> ___sys_recvmsg+0x127/0x200 net/socket.c:2674<br /> __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7fdfd5954c29<br /> 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29<br /> RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005<br /> RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60<br /> R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54<br /> <br /> <br /> addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame:<br /> ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246<br /> <br /> this frame has 1 object:<br /> [32, 160) &amp;#39;addr&amp;#39;<br /> <br /> Memory state around the buggy address:<br /> ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00<br /> ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00<br /> &gt;ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3<br /> ^<br /> ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1<br /> ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix hang during reboot/shutdown<br /> <br /> Recent commit 974578017fc1 ("iavf: Add waiting so the port is<br /> initialized in remove") adds a wait-loop at the beginning of<br /> iavf_remove() to ensure that port initialization is finished<br /> prior unregistering net device. This causes a regression<br /> in reboot/shutdown scenario because in this case callback<br /> iavf_shutdown() is called and this callback detaches the device,<br /> makes it down if it is running and sets its state to __IAVF_REMOVE.<br /> Later shutdown callback of associated PF driver (e.g. ice_shutdown)<br /> is called. That callback calls among other things sriov_disable()<br /> that calls indirectly iavf_remove() (see stack trace below).<br /> As the adapter state is already __IAVF_REMOVE then the mentioned<br /> loop is end-less and shutdown process hangs.<br /> <br /> The patch fixes this by checking adapter&amp;#39;s state at the beginning<br /> of iavf_remove() and skips the rest of the function if the adapter<br /> is already in remove state (shutdown is in progress).<br /> <br /> Reproducer:<br /> 1. Create VF on PF driven by ice or i40e driver<br /> 2. Ensure that the VF is bound to iavf driver<br /> 3. Reboot<br /> <br /> [52625.981294] sysrq: SysRq : Show Blocked State<br /> [52625.988377] task:reboot state:D stack: 0 pid:17359 ppid: 1 f2<br /> [52625.996732] Call Trace:<br /> [52625.999187] __schedule+0x2d1/0x830<br /> [52626.007400] schedule+0x35/0xa0<br /> [52626.010545] schedule_hrtimeout_range_clock+0x83/0x100<br /> [52626.020046] usleep_range+0x5b/0x80<br /> [52626.023540] iavf_remove+0x63/0x5b0 [iavf]<br /> [52626.027645] pci_device_remove+0x3b/0xc0<br /> [52626.031572] device_release_driver_internal+0x103/0x1f0<br /> [52626.036805] pci_stop_bus_device+0x72/0xa0<br /> [52626.040904] pci_stop_and_remove_bus_device+0xe/0x20<br /> [52626.045870] pci_iov_remove_virtfn+0xba/0x120<br /> [52626.050232] sriov_disable+0x2f/0xe0<br /> [52626.053813] ice_free_vfs+0x7c/0x340 [ice]<br /> [52626.057946] ice_remove+0x220/0x240 [ice]<br /> [52626.061967] ice_shutdown+0x16/0x50 [ice]<br /> [52626.065987] pci_device_shutdown+0x34/0x60<br /> [52626.070086] device_shutdown+0x165/0x1c5<br /> [52626.074011] kernel_restart+0xe/0x30<br /> [52626.077593] __do_sys_reboot+0x1d2/0x210<br /> [52626.093815] do_syscall_64+0x5b/0x1a0<br /> [52626.097483] entry_SYSCALL_64_after_hwframe+0x65/0xca

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats()<br /> <br /> It is possible to do NULL pointer dereference in routine that updates<br /> Tx ring stats. Currently only stats and bytes are updated when ring<br /> pointer is valid, but later on ring is accessed to propagate gathered Tx<br /> stats onto VSI stats.<br /> <br /> Change the existing logic to move to next ring when ring is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix race condition during interface enslave<br /> <br /> Commit 5dbbbd01cbba83 ("ice: Avoid RTNL lock when re-creating<br /> auxiliary device") changes a process of re-creation of aux device<br /> so ice_plug_aux_dev() is called from ice_service_task() context.<br /> This unfortunately opens a race window that can result in dead-lock<br /> when interface has left LAG and immediately enters LAG again.<br /> <br /> Reproducer:<br /> ```<br /> #!/bin/sh<br /> <br /> ip link add lag0 type bond mode 1 miimon 100<br /> ip link set lag0<br /> <br /> for n in {1..10}; do<br /> echo Cycle: $n<br /> ip link set ens7f0 master lag0<br /> sleep 1<br /> ip link set ens7f0 nomaster<br /> done<br /> ```<br /> <br /> This results in:<br /> [20976.208697] Workqueue: ice ice_service_task [ice]<br /> [20976.213422] Call Trace:<br /> [20976.215871] __schedule+0x2d1/0x830<br /> [20976.219364] schedule+0x35/0xa0<br /> [20976.222510] schedule_preempt_disabled+0xa/0x10<br /> [20976.227043] __mutex_lock.isra.7+0x310/0x420<br /> [20976.235071] enum_all_gids_of_dev_cb+0x1c/0x100 [ib_core]<br /> [20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core]<br /> [20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core]<br /> [20976.261079] ib_register_device+0x40d/0x580 [ib_core]<br /> [20976.266139] irdma_ib_register_device+0x129/0x250 [irdma]<br /> [20976.281409] irdma_probe+0x2c1/0x360 [irdma]<br /> [20976.285691] auxiliary_bus_probe+0x45/0x70<br /> [20976.289790] really_probe+0x1f2/0x480<br /> [20976.298509] driver_probe_device+0x49/0xc0<br /> [20976.302609] bus_for_each_drv+0x79/0xc0<br /> [20976.306448] __device_attach+0xdc/0x160<br /> [20976.310286] bus_probe_device+0x9d/0xb0<br /> [20976.314128] device_add+0x43c/0x890<br /> [20976.321287] __auxiliary_device_add+0x43/0x60<br /> [20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice]<br /> [20976.330109] ice_service_task+0xd0c/0xed0 [ice]<br /> [20976.342591] process_one_work+0x1a7/0x360<br /> [20976.350536] worker_thread+0x30/0x390<br /> [20976.358128] kthread+0x10a/0x120<br /> [20976.365547] ret_from_fork+0x1f/0x40<br /> ...<br /> [20976.438030] task:ip state:D stack: 0 pid:213658 ppid:213627 flags:0x00004084<br /> [20976.446469] Call Trace:<br /> [20976.448921] __schedule+0x2d1/0x830<br /> [20976.452414] schedule+0x35/0xa0<br /> [20976.455559] schedule_preempt_disabled+0xa/0x10<br /> [20976.460090] __mutex_lock.isra.7+0x310/0x420<br /> [20976.464364] device_del+0x36/0x3c0<br /> [20976.467772] ice_unplug_aux_dev+0x1a/0x40 [ice]<br /> [20976.472313] ice_lag_event_handler+0x2a2/0x520 [ice]<br /> [20976.477288] notifier_call_chain+0x47/0x70<br /> [20976.481386] __netdev_upper_dev_link+0x18b/0x280<br /> [20976.489845] bond_enslave+0xe05/0x1790 [bonding]<br /> [20976.494475] do_setlink+0x336/0xf50<br /> [20976.502517] __rtnl_newlink+0x529/0x8b0<br /> [20976.543441] rtnl_newlink+0x43/0x60<br /> [20976.546934] rtnetlink_rcv_msg+0x2b1/0x360<br /> [20976.559238] netlink_rcv_skb+0x4c/0x120<br /> [20976.563079] netlink_unicast+0x196/0x230<br /> [20976.567005] netlink_sendmsg+0x204/0x3d0<br /> [20976.570930] sock_sendmsg+0x4c/0x50<br /> [20976.574423] ____sys_sendmsg+0x1eb/0x250<br /> [20976.586807] ___sys_sendmsg+0x7c/0xc0<br /> [20976.606353] __sys_sendmsg+0x57/0xa0<br /> [20976.609930] do_syscall_64+0x5b/0x1a0<br /> [20976.613598] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> 1. Command &amp;#39;ip link ... set nomaster&amp;#39; causes that ice_plug_aux_dev()<br /> is called from ice_service_task() context, aux device is created<br /> and associated device-&gt;lock is taken.<br /> 2. Command &amp;#39;ip link ... set master...&amp;#39; calls ice&amp;#39;s notifier under<br /> RTNL lock and that notifier calls ice_unplug_aux_dev(). That<br /> function tries to take aux device-&gt;lock but this is already taken<br /> by ice_plug_aux_dev() in step 1<br /> 3. Later ice_plug_aux_dev() tries to take RTNL lock but this is already<br /> taken in step 2<br /> 4. Dead-lock<br /> <br /> The patch fixes this issue by following changes:<br /> - Bit ICE_FLAG_PLUG_AUX_DEV is kept to be set during ice_plug_aux_dev()<br /> call in ice_service_task()<br /> - The bit is checked in ice_clear_rdma_cap() and only if it is not set<br /> then ice_unplug_aux_dev() is called. If it is set (in other words<br /> plugging of aux device was requested and ice_plug_aux_dev() is<br /> potentially running) then the function only clears the<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: Fix leaking sent_cmd skb<br /> <br /> sent_cmd memory is not freed before freeing hci_dev causing it to leak<br /> it contents.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: smp: fill in sibling and core maps earlier<br /> <br /> After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),<br /> 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting<br /> the following:<br /> <br /> [ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))<br /> [ 0.048183] ------------[ cut here ]------------<br /> [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240<br /> [ 0.048220] Modules linked in:<br /> [ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f<br /> [ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1<br /> [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000<br /> [ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000<br /> [ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34<br /> [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933<br /> [ 0.048389] ...<br /> [ 0.048396] Call Trace:<br /> [ 0.048399] [] show_stack+0x3c/0x140<br /> [ 0.048424] [] dump_stack_lvl+0x60/0x80<br /> [ 0.048440] [] __warn+0xc0/0xf4<br /> [ 0.048454] [] warn_slowpath_fmt+0x64/0x10c<br /> [ 0.048467] [] sched_core_cpu_starting+0x198/0x240<br /> [ 0.048483] [] sched_cpu_starting+0x14/0x80<br /> [ 0.048497] [] cpuhp_invoke_callback_range+0x78/0x140<br /> [ 0.048510] [] notify_cpu_starting+0x94/0x140<br /> [ 0.048523] [] start_secondary+0xbc/0x280<br /> [ 0.048539]<br /> [ 0.048543] ---[ end trace 0000000000000000 ]---<br /> [ 0.048636] Synchronize counters for CPU 1: done.<br /> <br /> ...for each but CPU 0/boot.<br /> Basic debug printks right before the mentioned line say:<br /> <br /> [ 0.048170] CPU: 1, smt_mask:<br /> <br /> So smt_mask, which is sibling mask obviously, is empty when entering<br /> the function.<br /> This is critical, as sched_core_cpu_starting() calculates<br /> core-scheduling parameters only once per CPU start, and it&amp;#39;s crucial<br /> to have all the parameters filled in at that moment (at least it<br /> uses cpu_smt_mask() which in fact is `&amp;cpu_sibling_map[cpu]` on<br /> MIPS).<br /> <br /> A bit of debugging led me to that set_cpu_sibling_map() performing<br /> the actual map calculation, was being invocated after<br /> notify_cpu_start(), and exactly the latter function starts CPU HP<br /> callback round (sched_core_cpu_starting() is basically a CPU HP<br /> callback).<br /> While the flow is same on ARM64 (maps after the notifier, although<br /> before calling set_cpu_online()), x86 started calculating sibling<br /> maps earlier than starting the CPU HP callbacks in Linux 4.14 (see<br /> [0] for the reference). Neither me nor my brief tests couldn&amp;#39;t find<br /> any potential caveats in calculating the maps right after performing<br /> delay calibration, but the WARN splat is now gone.<br /> The very same debug prints now yield exactly what I expected from<br /> them:<br /> <br /> [ 0.048433] CPU: 1, smt_mask: 0-1<br /> <br /> [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: release rq qos structures for queue without disk<br /> <br /> blkcg_init_queue() may add rq qos structures to request queue, previously<br /> blk_cleanup_queue() calls rq_qos_exit() to release them, but commit<br /> 8e141f9eb803 ("block: drain file system I/O on del_gendisk")<br /> moves rq_qos_exit() into del_gendisk(), so memory leak is caused<br /> because queues may not have disk, such as un-present scsi luns, nvme<br /> admin queue, ...<br /> <br /> Fixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back.<br /> <br /> BTW, v5.18 won&amp;#39;t need this patch any more since we move<br /> blkcg_init_queue()/blkcg_exit_queue() into disk allocation/release<br /> handler, and patches have been in for-5.18/block.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watch_queue: Fix filter limit check<br /> <br /> In watch_queue_set_filter(), there are a couple of places where we check<br /> that the filter type value does not exceed what the type_filter bitmap<br /> can hold. One place calculates the number of bits by:<br /> <br /> if (tf[i].type &gt;= sizeof(wfilter-&gt;type_filter) * 8)<br /> <br /> which is fine, but the second does:<br /> <br /> if (tf[i].type &gt;= sizeof(wfilter-&gt;type_filter) * BITS_PER_LONG)<br /> <br /> which is not. This can lead to a couple of out-of-bounds writes due to<br /> a too-large type:<br /> <br /> (1) __set_bit() on wfilter-&gt;type_filter<br /> (2) Writing more elements in wfilter-&gt;filters[] than we allocated.<br /> <br /> Fix this by just using the proper WATCH_TYPE__NR instead, which is the<br /> number of types we actually know about.<br /> <br /> The bug may cause an oops looking something like:<br /> <br /> BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740<br /> Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x45/0x59<br /> print_address_description.constprop.0+0x1f/0x150<br /> ...<br /> kasan_report.cold+0x7f/0x11b<br /> ...<br /> watch_queue_set_filter+0x659/0x740<br /> ...<br /> __x64_sys_ioctl+0x127/0x190<br /> do_syscall_64+0x43/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Allocated by task 611:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x81/0xa0<br /> watch_queue_set_filter+0x23a/0x740<br /> __x64_sys_ioctl+0x127/0x190<br /> do_syscall_64+0x43/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The buggy address belongs to the object at ffff88800d2c66a0<br /> which belongs to the cache kmalloc-32 of size 32<br /> The buggy address is located 28 bytes inside of<br /> 32-byte region [ffff88800d2c66a0, ffff88800d2c66c0)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: skip reserved bytes warning on unmount after log cleanup failure<br /> <br /> After the recent changes made by commit c2e39305299f01 ("btrfs: clear<br /> extent buffer uptodate when we fail to write it") and its followup fix,<br /> commit 651740a5024117 ("btrfs: check WRITE_ERR when trying to read an<br /> extent buffer"), we can now end up not cleaning up space reservations of<br /> log tree extent buffers after a transaction abort happens, as well as not<br /> cleaning up still dirty extent buffers.<br /> <br /> This happens because if writeback for a log tree extent buffer failed,<br /> then we have cleared the bit EXTENT_BUFFER_UPTODATE from the extent buffer<br /> and we have also set the bit EXTENT_BUFFER_WRITE_ERR on it. Later on,<br /> when trying to free the log tree with free_log_tree(), which iterates<br /> over the tree, we can end up getting an -EIO error when trying to read<br /> a node or a leaf, since read_extent_buffer_pages() returns -EIO if an<br /> extent buffer does not have EXTENT_BUFFER_UPTODATE set and has the<br /> EXTENT_BUFFER_WRITE_ERR bit set. Getting that -EIO means that we return<br /> immediately as we can not iterate over the entire tree.<br /> <br /> In that case we never update the reserved space for an extent buffer in<br /> the respective block group and space_info object.<br /> <br /> When this happens we get the following traces when unmounting the fs:<br /> <br /> [174957.284509] BTRFS: error (device dm-0) in cleanup_transaction:1913: errno=-5 IO failure<br /> [174957.286497] BTRFS: error (device dm-0) in free_log_tree:3420: errno=-5 IO failure<br /> [174957.399379] ------------[ cut here ]------------<br /> [174957.402497] WARNING: CPU: 2 PID: 3206883 at fs/btrfs/block-group.c:127 btrfs_put_block_group+0x77/0xb0 [btrfs]<br /> [174957.407523] Modules linked in: btrfs overlay dm_zero (...)<br /> [174957.424917] CPU: 2 PID: 3206883 Comm: umount Tainted: G W 5.16.0-rc5-btrfs-next-109 #1<br /> [174957.426689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [174957.428716] RIP: 0010:btrfs_put_block_group+0x77/0xb0 [btrfs]<br /> [174957.429717] Code: 21 48 8b bd (...)<br /> [174957.432867] RSP: 0018:ffffb70d41cffdd0 EFLAGS: 00010206<br /> [174957.433632] RAX: 0000000000000001 RBX: ffff8b09c3848000 RCX: ffff8b0758edd1c8<br /> [174957.434689] RDX: 0000000000000001 RSI: ffffffffc0b467e7 RDI: ffff8b0758edd000<br /> [174957.436068] RBP: ffff8b0758edd000 R08: 0000000000000000 R09: 0000000000000000<br /> [174957.437114] R10: 0000000000000246 R11: 0000000000000000 R12: ffff8b09c3848148<br /> [174957.438140] R13: ffff8b09c3848198 R14: ffff8b0758edd188 R15: dead000000000100<br /> [174957.439317] FS: 00007f328fb82800(0000) GS:ffff8b0a2d200000(0000) knlGS:0000000000000000<br /> [174957.440402] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [174957.441164] CR2: 00007fff13563e98 CR3: 0000000404f4e005 CR4: 0000000000370ee0<br /> [174957.442117] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [174957.443076] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [174957.443948] Call Trace:<br /> [174957.444264] <br /> [174957.444538] btrfs_free_block_groups+0x255/0x3c0 [btrfs]<br /> [174957.445238] close_ctree+0x301/0x357 [btrfs]<br /> [174957.445803] ? call_rcu+0x16c/0x290<br /> [174957.446250] generic_shutdown_super+0x74/0x120<br /> [174957.446832] kill_anon_super+0x14/0x30<br /> [174957.447305] btrfs_kill_super+0x12/0x20 [btrfs]<br /> [174957.447890] deactivate_locked_super+0x31/0xa0<br /> [174957.448440] cleanup_mnt+0x147/0x1c0<br /> [174957.448888] task_work_run+0x5c/0xa0<br /> [174957.449336] exit_to_user_mode_prepare+0x1e5/0x1f0<br /> [174957.449934] syscall_exit_to_user_mode+0x16/0x40<br /> [174957.450512] do_syscall_64+0x48/0xc0<br /> [174957.450980] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [174957.451605] RIP: 0033:0x7f328fdc4a97<br /> [174957.452059] Code: 03 0c 00 f7 (...)<br /> [174957.454320] RSP: 002b:00007fff13564ec8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6<br /> [174957.455262] RAX: 0000000000000000 RBX: 00007f328feea264 RCX: 00007f328fdc4a97<br /> [174957.456131] RDX: 0000000000000000 RSI: 00000000000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: usbtmc: Fix bug in pipe direction for control transfers<br /> <br /> The syzbot fuzzer reported a minor bug in the usbtmc driver:<br /> <br /> usb 5-1: BOGUS control dir, pipe 80001e80 doesn&amp;#39;t match bRequestType 0<br /> WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412<br /> usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410<br /> Modules linked in:<br /> CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted<br /> 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0<br /> ...<br /> Call Trace:<br /> <br /> usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58<br /> usb_internal_control_msg drivers/usb/core/message.c:102 [inline]<br /> usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153<br /> usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [inline]<br /> <br /> The problem is that usbtmc_ioctl_request() uses usb_rcvctrlpipe() for<br /> all of its transfers, whether they are in or out. It&amp;#39;s easy to fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: avoid double fput() on failed usercopy<br /> <br /> If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF<br /> ioctl(), we shouldn&amp;#39;t assume that &amp;#39;buf-&gt;dmabuf&amp;#39; is still valid. In fact,<br /> dma_buf_fd() called fd_install() before, i.e. "consumed" one reference,<br /> leaving us with none.<br /> <br /> Calling dma_buf_put() will therefore put a reference we no longer own,<br /> leading to a valid file descritor table entry for an already released<br /> &amp;#39;file&amp;#39; object which is a straight use-after-free.<br /> <br /> Simply avoid calling dma_buf_put() and rely on the process exit code to<br /> do the necessary cleanup, if needed, i.e. if the file descriptor is<br /> still valid.