Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: bq27xxx: Fix poll_interval handling and races on remove<br /> <br /> Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0<br /> to avoid bq27xxx_battery_update() requeuing the delayed_work item.<br /> <br /> There are 2 problems with this:<br /> <br /> 1. If the driver is unbound through sysfs, rather then the module being<br /> rmmod-ed, this changes poll_interval unexpectedly<br /> <br /> 2. This is racy, after it being set poll_interval could be changed<br /> before bq27xxx_battery_update() checks it through<br /> /sys/module/bq27xxx_battery/parameters/poll_interval<br /> <br /> Fix this by added a removed attribute to struct bq27xxx_device_info and<br /> using that instead of setting poll_interval to 0.<br /> <br /> There also is another poll_interval related race on remove(), writing<br /> /sys/module/bq27xxx_battery/parameters/poll_interval will requeue<br /> the delayed_work item for all devices on the bq27xxx_battery_devices<br /> list and the device being removed was only removed from that list<br /> after cancelling the delayed_work item.<br /> <br /> Fix this by moving the removal from the bq27xxx_battery_devices list<br /> to before cancelling the delayed_work item.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: skip splitting and logical rewriting on pre-alloc write<br /> <br /> When doing a relocation, there is a chance that at the time of<br /> btrfs_reloc_clone_csums(), there is no checksum for the corresponding<br /> region.<br /> <br /> In this case, btrfs_finish_ordered_zoned()&amp;#39;s sum points to an invalid item<br /> and so ordered_extent&amp;#39;s logical is set to some invalid value. Then,<br /> btrfs_lookup_block_group() in btrfs_zone_finish_endio() failed to find a<br /> block group and will hit an assert or a null pointer dereference as<br /> following.<br /> <br /> This can be reprodcued by running btrfs/028 several times (e.g, 4 to 16<br /> times) with a null_blk setup. The device&amp;#39;s zone size and capacity is set to<br /> 32 MB and the storage size is set to 5 GB on my setup.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]<br /> CPU: 6 PID: 3105720 Comm: kworker/u16:13 Tainted: G W 6.5.0-rc6-kts+ #1<br /> Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015<br /> Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]<br /> RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]<br /> Code: 41 54 49 89 fc 55 48 89 f5 53 e8 57 7d fc ff 48 8d b8 88 00 00 00 48 89 c3 48 b8 00 00 00 00 00<br /> &gt; 3c 02 00 0f 85 02 01 00 00 f6 83 88 00 00 00 01 0f 84 a8 00 00<br /> RSP: 0018:ffff88833cf87b08 EFLAGS: 00010206<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088<br /> RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed102877b827<br /> R10: ffff888143bdc13b R11: ffff888125b1cbc0 R12: ffff888143bdc000<br /> R13: 0000000000007000 R14: ffff888125b1cba8 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff88881e500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f3ed85223d5 CR3: 00000001519b4005 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ? die_addr+0x3c/0xa0<br /> ? exc_general_protection+0x148/0x220<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]<br /> ? btrfs_zone_finish_endio.part.0+0x19/0x160 [btrfs]<br /> btrfs_finish_one_ordered+0x7b8/0x1de0 [btrfs]<br /> ? rcu_is_watching+0x11/0xb0<br /> ? lock_release+0x47a/0x620<br /> ? btrfs_finish_ordered_zoned+0x59b/0x800 [btrfs]<br /> ? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs]<br /> ? btrfs_finish_ordered_zoned+0x358/0x800 [btrfs]<br /> ? __smp_call_single_queue+0x124/0x350<br /> ? rcu_is_watching+0x11/0xb0<br /> btrfs_work_helper+0x19f/0xc60 [btrfs]<br /> ? __pfx_try_to_wake_up+0x10/0x10<br /> ? _raw_spin_unlock_irq+0x24/0x50<br /> ? rcu_is_watching+0x11/0xb0<br /> process_one_work+0x8c1/0x1430<br /> ? __pfx_lock_acquire+0x10/0x10<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? __pfx_do_raw_spin_lock+0x10/0x10<br /> ? _raw_spin_lock_irq+0x52/0x60<br /> worker_thread+0x100/0x12c0<br /> ? __kthread_parkme+0xc1/0x1f0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x2ea/0x3c0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x70<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> On the zoned mode, writing to pre-allocated region means data relocation<br /> write. Such write always uses WRITE command so there is no need of splitting<br /> and rewriting logical address. Thus, we can just skip the function for the<br /> case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen: speed up grant-table reclaim<br /> <br /> When a grant entry is still in use by the remote domain, Linux must put<br /> it on a deferred list. Normally, this list is very short, because<br /> the PV network and block protocols expect the backend to unmap the grant<br /> first. However, Qubes OS&amp;#39;s GUI protocol is subject to the constraints<br /> of the X Window System, and as such winds up with the frontend unmapping<br /> the window first. As a result, the list can grow very large, resulting<br /> in a massive memory leak and eventual VM freeze.<br /> <br /> To partially solve this problem, make the number of entries that the VM<br /> will attempt to free at each iteration tunable. The default is still<br /> 10, but it can be overridden via a module parameter.<br /> <br /> This is Cc: stable because (when combined with appropriate userspace<br /> changes) it fixes a severe performance and stability problem for Qubes<br /> OS users.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix OOB read in indx_insert_into_buffer<br /> <br /> Syzbot reported a OOB read bug:<br /> <br /> BUG: KASAN: slab-out-of-bounds in indx_insert_into_buffer+0xaa3/0x13b0<br /> fs/ntfs3/index.c:1755<br /> Read of size 17168 at addr ffff8880255e06c0 by task syz-executor308/3630<br /> <br /> Call Trace:<br /> <br /> memmove+0x25/0x60 mm/kasan/shadow.c:54<br /> indx_insert_into_buffer+0xaa3/0x13b0 fs/ntfs3/index.c:1755<br /> indx_insert_entry+0x446/0x6b0 fs/ntfs3/index.c:1863<br /> ntfs_create_inode+0x1d3f/0x35c0 fs/ntfs3/inode.c:1548<br /> ntfs_create+0x3e/0x60 fs/ntfs3/namei.c:100<br /> lookup_open fs/namei.c:3413 [inline]<br /> <br /> If the member struct INDEX_BUFFER *index of struct indx_node is<br /> incorrect, that is, the value of __le32 used is greater than the value<br /> of __le32 total in struct INDEX_HDR. Therefore, OOB read occurs when<br /> memmove is called in indx_insert_into_buffer().<br /> Fix this by adding a check in hdr_find_e().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi:ssif: Fix a memory leak when scanning for an adapter<br /> <br /> The adapter scan ssif_info_find() sets info-&gt;adapter_name if the adapter<br /> info came from SMBIOS, as it&amp;#39;s not set in that case. However, this<br /> function can be called more than once, and it will leak the adapter name<br /> if it had already been set. So check for NULL before setting it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: realtek: fix out-of-bounds access<br /> <br /> The probe function sets priv-&gt;chip_data to (void *)priv + sizeof(*priv)<br /> with the expectation that priv has enough trailing space.<br /> <br /> However, only realtek-smi actually allocated this chip_data space.<br /> Do likewise in realtek-mdio to fix out-of-bounds accesses.<br /> <br /> These accesses likely went unnoticed so far, because of an (unused)<br /> buf[4096] member in struct realtek_priv, which caused kmalloc to<br /> round up the allocated buffer to a big enough size, so nothing of<br /> value was overwritten. With a different allocator (like in the barebox<br /> bootloader port of the driver) or with KASAN, the memory corruption<br /> becomes quickly apparent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-usb-v2: gl861: Fix null-ptr-deref in gl861_i2c_master_xfer<br /> <br /> In gl861_i2c_master_xfer, msg is controlled by user. When msg[i].buf<br /> is null and msg[i].len is zero, former checks on msg[i].buf would be<br /> passed. Malicious data finally reach gl861_i2c_master_xfer. If accessing<br /> msg[i].buf[0] without sanity check, null ptr deref would happen.<br /> We add check on msg[i].len to prevent crash.<br /> <br /> Similar commit:<br /> commit 0ed554fd769a<br /> ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race when deleting free space root from the dirty cow roots list<br /> <br /> When deleting the free space tree we are deleting the free space root<br /> from the list fs_info-&gt;dirty_cowonly_roots without taking the lock that<br /> protects it, which is struct btrfs_fs_info::trans_lock.<br /> This unsynchronized list manipulation may cause chaos if there&amp;#39;s another<br /> concurrent manipulation of this list, such as when adding a root to it<br /> with ctree.c:add_root_to_dirty_list().<br /> <br /> This can result in all sorts of weird failures caused by a race, such as<br /> the following crash:<br /> <br /> [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI<br /> [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1<br /> [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs]<br /> [337571.279928] Code: 85 38 06 00 (...)<br /> [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206<br /> [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000<br /> [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070<br /> [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b<br /> [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600<br /> [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48<br /> [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000<br /> [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0<br /> [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [337571.282874] Call Trace:<br /> [337571.283101] <br /> [337571.283327] ? __die_body+0x1b/0x60<br /> [337571.283570] ? die_addr+0x39/0x60<br /> [337571.283796] ? exc_general_protection+0x22e/0x430<br /> [337571.284022] ? asm_exc_general_protection+0x22/0x30<br /> [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs]<br /> [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs]<br /> [337571.284803] ? _raw_spin_unlock+0x15/0x30<br /> [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs]<br /> [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs]<br /> [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs]<br /> [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410<br /> [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs]<br /> [337571.286358] ? mod_objcg_state+0xd2/0x360<br /> [337571.286577] ? refill_obj_stock+0xb0/0x160<br /> [337571.286798] ? seq_release+0x25/0x30<br /> [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0<br /> [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0<br /> [337571.287455] ? __x64_sys_ioctl+0x88/0xc0<br /> [337571.287675] __x64_sys_ioctl+0x88/0xc0<br /> [337571.287901] do_syscall_64+0x38/0x90<br /> [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [337571.288352] RIP: 0033:0x7f478aaffe9b<br /> <br /> So fix this by locking struct btrfs_fs_info::trans_lock before deleting<br /> the free space root from that list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: fix to call f2fs_wait_on_page_writeback() in f2fs_write_raw_pages()<br /> <br /> BUG_ON() will be triggered when writing files concurrently,<br /> because the same page is writtenback multiple times.<br /> <br /> 1597 void folio_end_writeback(struct folio *folio)<br /> 1598 {<br /> ......<br /> 1618 if (!__folio_end_writeback(folio))<br /> 1619 BUG();<br /> ......<br /> 1625 }<br /> <br /> kernel BUG at mm/filemap.c:1619!<br /> Call Trace:<br /> <br /> f2fs_write_end_io+0x1a0/0x370<br /> blk_update_request+0x6c/0x410<br /> blk_mq_end_request+0x15/0x130<br /> blk_complete_reqs+0x3c/0x50<br /> __do_softirq+0xb8/0x29b<br /> ? sort_range+0x20/0x20<br /> run_ksoftirqd+0x19/0x20<br /> smpboot_thread_fn+0x10b/0x1d0<br /> kthread+0xde/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Below is the concurrency scenario:<br /> <br /> [Process A] [Process B] [Process C]<br /> f2fs_write_raw_pages()<br /> - redirty_page_for_writepage()<br /> - unlock page()<br /> f2fs_do_write_data_page()<br /> - lock_page()<br /> - clear_page_dirty_for_io()<br /> - set_page_writeback() [1st writeback]<br /> .....<br /> - unlock page()<br /> <br /> generic_perform_write()<br /> - f2fs_write_begin()<br /> - wait_for_stable_page()<br /> <br /> - f2fs_write_end()<br /> - set_page_dirty()<br /> <br /> - lock_page()<br /> - f2fs_do_write_data_page()<br /> - set_page_writeback() [2st writeback]<br /> <br /> This problem was introduced by the previous commit 7377e853967b ("f2fs:<br /> compress: fix potential deadlock of compress file"). All pagelocks were<br /> released in f2fs_write_raw_pages(), but whether the page was<br /> in the writeback state was ignored in the subsequent writing process.<br /> Let&amp;#39;s fix it by waiting for the page to writeback before writing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow<br /> <br /> When we calculate the end position of ext4_free_extent, this position may<br /> be exactly where ext4_lblk_t (i.e. uint) overflows. For example, if<br /> ac_g_ex.fe_logical is 4294965248 and ac_orig_goal_len is 2048, then the<br /> computed end is 0x100000000, which is 0. If ac-&gt;ac_o_ex.fe_logical is not<br /> the first case of adjusting the best extent, that is, new_bex_end &gt; 0, the<br /> following BUG_ON will be triggered:<br /> <br /> =========================================================<br /> kernel BUG at fs/ext4/mballoc.c:5116!<br /> invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 3 PID: 673 Comm: xfs_io Tainted: G E 6.5.0-rc1+ #279<br /> RIP: 0010:ext4_mb_new_inode_pa+0xc5/0x430<br /> Call Trace:<br /> <br /> ext4_mb_use_best_found+0x203/0x2f0<br /> ext4_mb_try_best_found+0x163/0x240<br /> ext4_mb_regular_allocator+0x158/0x1550<br /> ext4_mb_new_blocks+0x86a/0xe10<br /> ext4_ext_map_blocks+0xb0c/0x13a0<br /> ext4_map_blocks+0x2cd/0x8f0<br /> ext4_iomap_begin+0x27b/0x400<br /> iomap_iter+0x222/0x3d0<br /> __iomap_dio_rw+0x243/0xcb0<br /> iomap_dio_rw+0x16/0x80<br /> =========================================================<br /> <br /> A simple reproducer demonstrating the problem:<br /> <br /> mkfs.ext4 -F /dev/sda -b 4096 100M<br /> mount /dev/sda /tmp/test<br /> fallocate -l1M /tmp/test/tmp<br /> fallocate -l10M /tmp/test/file<br /> fallocate -i -o 1M -l16777203M /tmp/test/file<br /> fsstress -d /tmp/test -l 0 -n 100000 -p 8 &amp;<br /> sleep 10 &amp;&amp; killall -9 fsstress<br /> rm -f /tmp/test/tmp<br /> xfs_io -c "open -ad /tmp/test/file" -c "pwrite -S 0xff 0 8192"<br /> <br /> We simply refactor the logic for adjusting the best extent by adding<br /> a temporary ext4_free_extent ex and use extent_logical_end() to avoid<br /> overflow, which also simplifies the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: clean up in all error paths when enabling SR-IOV<br /> <br /> After commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removing<br /> the igb module could hang or crash (depending on the machine) when the<br /> module has been loaded with the max_vfs parameter set to some value != 0.<br /> <br /> In case of one test machine with a dual port 82580, this hang occurred:<br /> <br /> [ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1<br /> [ 233.093257] igb 0000:41:00.1: IOV Disabled<br /> [ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0<br /> [ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)<br /> [ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000<br /> [ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First)<br /> [ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c<br /> [ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)<br /> [ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000<br /> [ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First)<br /> [ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c<br /> [ 233.538214] pci 0000:41:00.1: AER: can&amp;#39;t recover (no error_detected callback)<br /> [ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0<br /> [ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed<br /> [ 234.157244] igb 0000:41:00.0: IOV Disabled<br /> [ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.<br /> [ 371.627489] Not tainted 6.4.0-dirty #2<br /> [ 371.632257] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this.<br /> [ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0<br /> [ 371.650330] Call Trace:<br /> [ 371.653061] <br /> [ 371.655407] __schedule+0x20e/0x660<br /> [ 371.659313] schedule+0x5a/0xd0<br /> [ 371.662824] schedule_preempt_disabled+0x11/0x20<br /> [ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0<br /> [ 371.673237] ? __pfx_aer_root_reset+0x10/0x10<br /> [ 371.678105] report_error_detected+0x25/0x1c0<br /> [ 371.682974] ? __pfx_report_normal_detected+0x10/0x10<br /> [ 371.688618] pci_walk_bus+0x72/0x90<br /> [ 371.692519] pcie_do_recovery+0xb2/0x330<br /> [ 371.696899] aer_process_err_devices+0x117/0x170<br /> [ 371.702055] aer_isr+0x1c0/0x1e0<br /> [ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0<br /> [ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10<br /> [ 371.715496] irq_thread_fn+0x20/0x60<br /> [ 371.719491] irq_thread+0xe6/0x1b0<br /> [ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10<br /> [ 371.728255] ? __pfx_irq_thread+0x10/0x10<br /> [ 371.732731] kthread+0xe2/0x110<br /> [ 371.736243] ? __pfx_kthread+0x10/0x10<br /> [ 371.740430] ret_from_fork+0x2c/0x50<br /> [ 371.744428] <br /> <br /> The reproducer was a simple script:<br /> <br /> #!/bin/sh<br /> for i in `seq 1 5`; do<br /> modprobe -rv igb<br /> modprobe -v igb max_vfs=1<br /> sleep 1<br /> modprobe -rv igb<br /> done<br /> <br /> It turned out that this could only be reproduce on 82580 (quad and<br /> dual-port), but not on 82576, i350 and i210. Further debugging showed<br /> that igb_enable_sriov()&amp;#39;s call to pci_enable_sriov() is failing, because<br /> dev-&gt;is_physfn is 0 on 82580.<br /> <br /> Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"),<br /> igb_enable_sriov() jumped into the "err_out" cleanup branch. After this<br /> commit it only returned the error code.<br /> <br /> So the cleanup didn&amp;#39;t take place, and the incorrect VF setup in the<br /> igb_adapter structure fooled the igb driver into assuming that VFs have<br /> been set up where no VF actually existed.<br /> <br /> Fix this problem by cleaning up again if pci_enable_sriov() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: use work to update rate to avoid RCU warning<br /> <br /> The ieee80211_ops::sta_rc_update must be atomic, because<br /> ieee80211_chan_bw_change() holds rcu_read lock while calling<br /> drv_sta_rc_update(), so create a work to do original things.<br /> <br /> Voluntary context switch within RCU read-side critical section!<br /> WARNING: CPU: 0 PID: 4621 at kernel/rcu/tree_plugin.h:318<br /> rcu_note_context_switch+0x571/0x5d0<br /> CPU: 0 PID: 4621 Comm: kworker/u16:2 Tainted: G W OE<br /> Workqueue: phy3 ieee80211_chswitch_work [mac80211]<br /> RIP: 0010:rcu_note_context_switch+0x571/0x5d0<br /> Call Trace:<br /> <br /> __schedule+0xb0/0x1460<br /> ? __mod_timer+0x116/0x360<br /> schedule+0x5a/0xc0<br /> schedule_timeout+0x87/0x150<br /> ? trace_raw_output_tick_stop+0x60/0x60<br /> wait_for_completion_timeout+0x7b/0x140<br /> usb_start_wait_urb+0x82/0x160 [usbcore<br /> usb_control_msg+0xe3/0x140 [usbcore<br /> rtw_usb_read+0x88/0xe0 [rtw_usb<br /> rtw_usb_read8+0xf/0x10 [rtw_usb<br /> rtw_fw_send_h2c_command+0xa0/0x170 [rtw_core<br /> rtw_fw_send_ra_info+0xc9/0xf0 [rtw_core<br /> drv_sta_rc_update+0x7c/0x160 [mac80211<br /> ieee80211_chan_bw_change+0xfb/0x110 [mac80211<br /> ieee80211_change_chanctx+0x38/0x130 [mac80211<br /> ieee80211_vif_use_reserved_switch+0x34e/0x900 [mac80211<br /> ieee80211_link_use_reserved_context+0x88/0xe0 [mac80211<br /> ieee80211_chswitch_work+0x95/0x170 [mac80211<br /> process_one_work+0x201/0x410<br /> worker_thread+0x4a/0x3b0<br /> ? process_one_work+0x410/0x410<br /> kthread+0xe1/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x1f/0x30<br />