Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem<br /> <br /> When the mapping is already reaped the unmap must be a no-op, as we<br /> would otherwise try to remove the mapping twice, corrupting the involved<br /> data structures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock<br /> <br /> When user_dlm_destroy_lock failed, it didn&amp;#39;t clean up the flags it set<br /> before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of<br /> lock is still in used, next time when unlink invokes this function, it<br /> will return succeed, and then unlink will remove inode and dentry if lock<br /> is not in used(file closed), but the dlm lock is still linked in dlm lock<br /> resource, then when bast come in, it will trigger a panic due to<br /> user-after-free. See the following panic call trace. To fix this,<br /> USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should<br /> be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink<br /> fail.<br /> <br /> For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,<br /> USER_LOCK_BUSY is also required to be cleared. Even though spin lock is<br /> released in between, but USER_LOCK_IN_TEARDOWN is still set, for<br /> USER_LOCK_BUSY, if before every place that waits on this flag,<br /> USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow<br /> waits on the busy flag set by user_dlm_destroy_lock(), then we can<br /> simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix<br /> user_dlm_cluster_lock() which is the only function not following this.<br /> <br /> [ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink<br /> 004fb0000060000b5a90b8c847b72e1, error -16 from destroy<br /> [ 989.757536] ------------[ cut here ]------------<br /> [ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!<br /> [ 989.757876] invalid opcode: 0000 [#1] SMP<br /> [ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)<br /> ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc<br /> xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5<br /> auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs<br /> ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc<br /> fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc<br /> rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad<br /> rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)<br /> mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad<br /> ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support<br /> pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si<br /> ipmi_msghandler<br /> [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp<br /> pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel<br /> be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio<br /> libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi<br /> dm_mirror dm_region_hash dm_log dm_mod [last unloaded:<br /> ksplice_2zhuk2jr_ib_ipoib_old]<br /> [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE<br /> 4.1.12-124.57.1.el6uek.x86_64 #2<br /> [ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER<br /> X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021<br /> [ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:<br /> ffff88017f7c8000<br /> [ 989.762848] RIP: e030:[] []<br /> __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs]<br /> [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246<br /> [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX:<br /> 0000000000000003<br /> [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI:<br /> ffff880174d48170<br /> [ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09:<br /> 0000000000000000<br /> [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12:<br /> ffff880174d48008<br /> [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15:<br /> ffff88021db7a000<br /> [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000)<br /> knlGS:ffff880247480000<br /> [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4:<br /> 0000000000042660<br /> [ 989.765081] Stack:<br /> [ 989.765167] 00000000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: CT: Fix cleanup of CT before cleanup of TC ct rules<br /> <br /> CT cleanup assumes that all tc rules were deleted first, and so<br /> is free to delete the CT shared resources (e.g the dr_action<br /> fwd_action which is shared for all tuples). But currently for<br /> uplink, this is happens in reverse, causing the below trace.<br /> <br /> CT cleanup is called from:<br /> mlx5e_cleanup_rep_tx()-&gt;mlx5e_cleanup_uplink_rep_tx()-&gt;<br /> mlx5e_rep_tc_cleanup()-&gt;mlx5e_tc_esw_cleanup()-&gt;<br /> mlx5_tc_ct_clean()<br /> <br /> Only afterwards, tc cleanup is called from:<br /> mlx5e_cleanup_rep_tx()-&gt;mlx5e_tc_ht_cleanup()<br /> which would have deleted all the tc ct rules, and so delete<br /> all the offloaded tuples.<br /> <br /> Fix this reversing the order of init and on cleanup, which<br /> will result in tc cleanup then ct cleanup.<br /> <br /> [ 9443.593347] WARNING: CPU: 2 PID: 206774 at drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1882 mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]<br /> [ 9443.593349] Modules linked in: act_ct nf_flow_table rdma_ucm(O) rdma_cm(O) iw_cm(O) ib_ipoib(O) ib_cm(O) ib_umad(O) mlx5_core(O-) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) psample ib_core(O) mlx_compat(O) ip_gre gre ip_tunnel act_vlan bonding geneve esp6_offload esp6 esp4_offload esp4 act_tunnel_key vxlan ip6_udp_tunnel udp_tunnel act_mirred act_skbedit act_gact cls_flower sch_ingress nfnetlink_cttimeout nfnetlink xfrm_user xfrm_algo 8021q garp stp ipmi_devintf mrp ipmi_msghandler llc openvswitch nsh nf_conncount nf_nat mst_pciconf(O) dm_multipath sbsa_gwdt uio_pdrv_genirq uio mlxbf_pmc mlxbf_pka mlx_trio mlx_bootctl(O) bluefield_edac sch_fq_codel ip_tables ipv6 crc_ccitt btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 crct10dif_ce i2c_mlxbf gpio_mlxbf2 mlxbf_gige aes_neon_bs aes_neon_blk [last unloaded: mlx5_ib]<br /> [ 9443.593419] CPU: 2 PID: 206774 Comm: modprobe Tainted: G O 5.4.0-1023.24.gc14613d-bluefield #1<br /> [ 9443.593422] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:143ebaf Jan 11 2022<br /> [ 9443.593424] pstate: 20000005 (nzCv daif -PAN -UAO)<br /> [ 9443.593489] pc : mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]<br /> [ 9443.593545] lr : mlx5_ct_fs_smfs_destroy+0x24/0x30 [mlx5_core]<br /> [ 9443.593546] sp : ffff8000135dbab0<br /> [ 9443.593548] x29: ffff8000135dbab0 x28: ffff0003a6ab8e80<br /> [ 9443.593550] x27: 0000000000000000 x26: ffff0003e07d7000<br /> [ 9443.593552] x25: ffff800009609de0 x24: ffff000397fb2120<br /> [ 9443.593554] x23: ffff0003975c0000 x22: 0000000000000000<br /> [ 9443.593556] x21: ffff0003975f08c0 x20: ffff800009609de0<br /> [ 9443.593558] x19: ffff0003c8a13380 x18: 0000000000000014<br /> [ 9443.593560] x17: 0000000067f5f125 x16: 000000006529c620<br /> [ 9443.593561] x15: 000000000000000b x14: 0000000000000000<br /> [ 9443.593563] x13: 0000000000000002 x12: 0000000000000001<br /> [ 9443.593565] x11: ffff800011108868 x10: 0000000000000000<br /> [ 9443.593567] x9 : 0000000000000000 x8 : ffff8000117fb270<br /> [ 9443.593569] x7 : ffff0003ebc01288 x6 : 0000000000000000<br /> [ 9443.593571] x5 : ffff800009591ab8 x4 : fffffe000f6d9a20<br /> [ 9443.593572] x3 : 0000000080040001 x2 : fffffe000f6d9a20<br /> [ 9443.593574] x1 : ffff8000095901d8 x0 : 0000000000000025<br /> [ 9443.593577] Call trace:<br /> [ 9443.593634] mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]<br /> [ 9443.593688] mlx5_ct_fs_smfs_destroy+0x24/0x30 [mlx5_core]<br /> [ 9443.593743] mlx5_tc_ct_clean+0x34/0xa8 [mlx5_core]<br /> [ 9443.593797] mlx5e_tc_esw_cleanup+0x58/0x88 [mlx5_core]<br /> [ 9443.593851] mlx5e_rep_tc_cleanup+0x24/0x30 [mlx5_core]<br /> [ 9443.593905] mlx5e_cleanup_rep_tx+0x6c/0x78 [mlx5_core]<br /> [ 9443.593959] mlx5e_detach_netdev+0x74/0x98 [mlx5_core]<br /> [ 9443.594013] mlx5e_netdev_change_profile+0x70/0x180 [mlx5_core]<br /> [ 9443.594067] mlx5e_netdev_attach_nic_profile+0x34/0x40 [mlx5_core]<br /> [ 9443.594122] mlx5e_vport_rep_unload+0x15c/0x1a8 [mlx5_core]<br /> [ 9443.594177] mlx5_eswitch_unregister_vport_reps+0x228/0x298 [mlx5_core]<br /> [ 9443.594231] mlx5e_rep_remove+0x2c/0x38<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: unexport __init-annotated seg6_hmac_init()<br /> <br /> EXPORT_SYMBOL and __init is a bad combination because the .init.text<br /> section is freed up after the initialization. Hence, modules cannot<br /> use symbols annotated __init. The access to a freed symbol may end up<br /> with kernel panic.<br /> <br /> modpost used to detect it, but it has been broken for a decade.<br /> <br /> Recently, I fixed modpost so it started to warn it again, then this<br /> showed up in linux-next builds.<br /> <br /> There are two ways to fix it:<br /> <br /> - Remove __init<br /> - Remove EXPORT_SYMBOL<br /> <br /> I chose the latter for this case because the caller (net/ipv6/seg6.c)<br /> and the callee (net/ipv6/seg6_hmac.c) belong to the same module.<br /> It seems an internal function call in ipv6.ko.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip_gre: test csum_start instead of transport header<br /> <br /> GRE with TUNNEL_CSUM will apply local checksum offload on<br /> CHECKSUM_PARTIAL packets.<br /> <br /> ipgre_xmit must validate csum_start after an optional skb_pull,<br /> else lco_csum may trigger an overflow. The original check was<br /> <br /> if (csum &amp;&amp; skb_checksum_start(skb) data)<br /> return -EINVAL;<br /> <br /> This had false positives when skb_checksum_start is undefined:<br /> when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement<br /> was straightforward<br /> <br /> if (csum &amp;&amp; skb-&gt;ip_summed == CHECKSUM_PARTIAL &amp;&amp;<br /> skb_checksum_start(skb) data)<br /> return -EINVAL;<br /> <br /> But was eventually revised more thoroughly:<br /> - restrict the check to the only branch where needed, in an<br /> uncommon GRE path that uses header_ops and calls skb_pull.<br /> - test skb_transport_header, which is set along with csum_start<br /> in skb_partial_csum_set in the normal header_ops datapath.<br /> <br /> Turns out skbs can arrive in this branch without the transport<br /> header set, e.g., through BPF redirection.<br /> <br /> Revise the check back to check csum_start directly, and only if<br /> CHECKSUM_PARTIAL. Do leave the check in the updated location.<br /> Check field regardless of whether TUNNEL_CSUM is configured.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Clear prog-&gt;jited_len along prog-&gt;jited<br /> <br /> syzbot reported an illegal copy_to_user() attempt<br /> from bpf_prog_get_info_by_fd() [1]<br /> <br /> There was no repro yet on this bug, but I think<br /> that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns")<br /> is exposing a prior bug in bpf arm64.<br /> <br /> bpf_prog_get_info_by_fd() looks at prog-&gt;jited_len<br /> to determine if the JIT image can be copied out to user space.<br /> <br /> My theory is that syzbot managed to get a prog where prog-&gt;jited_len<br /> has been set to 43, while prog-&gt;bpf_func has ben cleared.<br /> <br /> It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering<br /> this particular warning.<br /> <br /> I thought find_vma_area(NULL) would not find a vm_struct.<br /> As we do not hold vmap_area_lock spinlock, it might be possible<br /> that the found vm_struct was garbage.<br /> <br /> [1]<br /> usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)!<br /> kernel BUG at mm/usercopy.c:101!<br /> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101<br /> lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89<br /> sp : ffff80000b773a20<br /> x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48<br /> x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000<br /> x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001<br /> x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd<br /> x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420<br /> x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031<br /> x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865<br /> x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830<br /> x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064<br /> Call trace:<br /> usercopy_abort+0x90/0x94 mm/usercopy.c:89<br /> check_heap_object mm/usercopy.c:186 [inline]<br /> __check_object_size mm/usercopy.c:252 [inline]<br /> __check_object_size+0x198/0x36c mm/usercopy.c:214<br /> check_object_size include/linux/thread_info.h:199 [inline]<br /> check_copy_size include/linux/thread_info.h:235 [inline]<br /> copy_to_user include/linux/uaccess.h:159 [inline]<br /> bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993<br /> bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253<br /> __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956<br /> __do_sys_bpf kernel/bpf/syscall.c:5021 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5019 [inline]<br /> __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019<br /> __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]<br /> invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52<br /> el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142<br /> do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206<br /> el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624<br /> el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581<br /> Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix sleeping function called from invalid context on RT kernel<br /> <br /> When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the<br /> cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the<br /> atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,<br /> these locks are replaced with sleepable rt-spinlock, so the stack calltrace will<br /> be triggered.<br /> Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start<br /> tp_printk=1" enabled.<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0<br /> preempt_count: 2, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> Preemption disabled at:<br /> [] try_to_wake_up+0x7e/0xba0<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x60/0x8c<br /> dump_stack+0x10/0x12<br /> __might_resched.cold+0x11d/0x155<br /> rt_spin_lock+0x40/0x70<br /> trace_event_buffer_commit+0x2fa/0x4c0<br /> ? map_vsyscall+0x93/0x93<br /> trace_event_raw_event_initcall_start+0xbe/0x110<br /> ? perf_trace_initcall_finish+0x210/0x210<br /> ? probe_sched_wakeup+0x34/0x40<br /> ? ttwu_do_wakeup+0xda/0x310<br /> ? trace_hardirqs_on+0x35/0x170<br /> ? map_vsyscall+0x93/0x93<br /> do_one_initcall+0x217/0x3c0<br /> ? trace_event_raw_event_initcall_level+0x170/0x170<br /> ? push_cpu_stop+0x400/0x400<br /> ? cblist_init_generic+0x241/0x290<br /> kernel_init_freeable+0x1ac/0x347<br /> ? _raw_spin_unlock_irq+0x65/0x80<br /> ? rest_init+0xf0/0xf0<br /> kernel_init+0x1e/0x150<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()<br /> <br /> It will cause null-ptr-deref when using &amp;#39;res&amp;#39;, if platform_get_resource()<br /> returns NULL, so move using &amp;#39;res&amp;#39; after devm_ioremap_resource() that<br /> will check it to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: cpc: Fix refcount leak in mips_cpc_default_phys_base<br /> <br /> Add the missing of_node_put() to release the refcount incremented<br /> by of_find_compatible_node().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: add accessors to read/set tp-&gt;snd_cwnd<br /> <br /> We had various bugs over the years with code<br /> breaking the assumption that tp-&gt;snd_cwnd is greater<br /> than zero.<br /> <br /> Lately, syzbot reported the WARN_ON_ONCE(!tp-&gt;prior_cwnd) added<br /> in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")<br /> can trigger, and without a repro we would have to spend<br /> considerable time finding the bug.<br /> <br /> Instead of complaining too late, we want to catch where<br /> and when tp-&gt;snd_cwnd is set to an illegal value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtl818x: Prevent using not initialized queues<br /> <br /> Using not existing queues can panic the kernel with rtl8180/rtl8185 cards.<br /> Ignore the skb priority for those cards, they only have one tx queue. Pierre<br /> Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:<br /> <br /> https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html<br /> <br /> He also confirmed that this patch fixes the issue. In summary this happened:<br /> <br /> After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a<br /> "divide error: 0000" when connecting to an AP. Control port tx now tries to<br /> use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in<br /> 2.10.<br /> <br /> Since only the rtl8187se part of the driver supports QoS, the priority<br /> of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185<br /> cards.<br /> <br /> rtl8180 is then unconditionally reading out the priority and finally crashes on<br /> drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this<br /> patch:<br /> idx = (ring-&gt;idx + skb_queue_len(&amp;ring-&gt;queue)) % ring-&gt;entries<br /> <br /> "ring-&gt;entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got<br /> initialized.