Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: f_fs: Fix use-after-free for epfile<br /> <br /> Consider a case where ffs_func_eps_disable is called from<br /> ffs_func_disable as part of composition switch and at the<br /> same time ffs_epfile_release get called from userspace.<br /> ffs_epfile_release will free up the read buffer and call<br /> ffs_data_closed which in turn destroys ffs-&gt;epfiles and<br /> mark it as NULL. While this was happening the driver has<br /> already initialized the local epfile in ffs_func_eps_disable<br /> which is now freed and waiting to acquire the spinlock. Once<br /> spinlock is acquired the driver proceeds with the stale value<br /> of epfile and tries to free the already freed read buffer<br /> causing use-after-free.<br /> <br /> Following is the illustration of the race:<br /> <br /> CPU1 CPU2<br /> <br /> ffs_func_eps_disable<br /> epfiles (local copy)<br /> ffs_epfile_release<br /> ffs_data_closed<br /> if (last file closed)<br /> ffs_data_reset<br /> ffs_data_clear<br /> ffs_epfiles_destroy<br /> spin_lock<br /> dereference epfiles<br /> <br /> Fix this races by taking epfiles local copy &amp; assigning it under<br /> spinlock and if epfiles(local) is null then update it in ffs-&gt;epfiles<br /> then finally destroy it.<br /> Extending the scope further from the race, protecting the ep related<br /> structures, and concurrent accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedf: Fix refcount issue when LOGO is received during TMF<br /> <br /> Hung task call trace was seen during LOGO processing.<br /> <br /> [ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued...<br /> [ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0<br /> [ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET<br /> [ 974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1.<br /> [ 974.309625] host1: rport 016900: Received LOGO request while in state Ready<br /> [ 974.309627] host1: rport 016900: Delete port<br /> [ 974.309642] host1: rport 016900: work event 3<br /> [ 974.309644] host1: rport 016900: lld callback ev 3<br /> [ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport is uploading, not executing flush.<br /> [ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: task mgmt command success...<br /> [ 984.031088] INFO: task jbd2/dm-15-8:7645 blocked for more than 120 seconds.<br /> [ 984.031136] Not tainted 4.18.0-305.el8.x86_64 #1<br /> <br /> [ 984.031166] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080<br /> [ 984.031212] Call Trace:<br /> [ 984.031222] __schedule+0x2c4/0x700<br /> [ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0<br /> [ 984.031233] ? bit_wait_timeout+0x90/0x90<br /> [ 984.031235] schedule+0x38/0xa0<br /> [ 984.031238] io_schedule+0x12/0x40<br /> [ 984.031240] bit_wait_io+0xd/0x50<br /> [ 984.031243] __wait_on_bit+0x6c/0x80<br /> [ 984.031248] ? free_buffer_head+0x21/0x50<br /> [ 984.031251] out_of_line_wait_on_bit+0x91/0xb0<br /> [ 984.031257] ? init_wait_var_entry+0x50/0x50<br /> [ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2]<br /> [ 984.031280] kjournald2+0xbd/0x270 [jbd2]<br /> [ 984.031284] ? finish_wait+0x80/0x80<br /> [ 984.031291] ? commit_timeout+0x10/0x10 [jbd2]<br /> [ 984.031294] kthread+0x116/0x130<br /> [ 984.031300] ? kthread_flush_work_fn+0x10/0x10<br /> [ 984.031305] ret_from_fork+0x1f/0x40<br /> <br /> There was a ref count issue when LOGO is received during TMF. This leads to<br /> one of the I/Os hanging with the driver. Fix the ref count.