Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()<br /> <br /> The free_rtllib() function frees the "dev" pointer so there is use<br /> after free on the next line. Re-arrange things to avoid that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nexthop: fix null pointer dereference when IPv6 is not enabled<br /> <br /> When we try to add an IPv6 nexthop and IPv6 is not enabled<br /> (!CONFIG_IPV6) we&amp;#39;ll hit a NULL pointer dereference[1] in the error path<br /> of nh_create_ipv6() due to calling ipv6_stub-&gt;fib6_nh_release. The bug<br /> has been present since the beginning of IPv6 nexthop gateway support.<br /> Commit 1aefd3de7bc6 ("ipv6: Add fib6_nh_init and release to stubs") tells<br /> us that only fib6_nh_init has a dummy stub because fib6_nh_release should<br /> not be called if fib6_nh_init returns an error, but the commit below added<br /> a call to ipv6_stub-&gt;fib6_nh_release in its error path. To fix it return<br /> the dummy stub&amp;#39;s -EAFNOSUPPORT error directly without calling<br /> ipv6_stub-&gt;fib6_nh_release in nh_create_ipv6()&amp;#39;s error path.<br /> <br /> [1]<br /> Output is a bit truncated, but it clearly shows the error.<br /> BUG: kernel NULL pointer dereference, address: 000000000000000000<br /> #PF: supervisor instruction fetch in kernel modede<br /> #PF: error_code(0x0010) - not-present pagege<br /> PGD 0 P4D 0<br /> Oops: 0010 [#1] PREEMPT SMP NOPTI<br /> CPU: 4 PID: 638 Comm: ip Kdump: loaded Not tainted 5.16.0-rc1+ #446<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.<br /> RSP: 0018:ffff888109f5b8f0 EFLAGS: 00010286^Ac<br /> RAX: 0000000000000000 RBX: ffff888109f5ba28 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8881008a2860<br /> RBP: ffff888109f5b9d8 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffff888109f5b978 R11: ffff888109f5b948 R12: 00000000ffffff9f<br /> R13: ffff8881008a2a80 R14: ffff8881008a2860 R15: ffff8881008a2840<br /> FS: 00007f98de70f100(0000) GS:ffff88822bf00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 0000000100efc000 CR4: 00000000000006e0<br /> Call Trace:<br /> <br /> nh_create_ipv6+0xed/0x10c<br /> rtm_new_nexthop+0x6d7/0x13f3<br /> ? check_preemption_disabled+0x3d/0xf2<br /> ? lock_is_held_type+0xbe/0xfd<br /> rtnetlink_rcv_msg+0x23f/0x26a<br /> ? check_preemption_disabled+0x3d/0xf2<br /> ? rtnl_calcit.isra.0+0x147/0x147<br /> netlink_rcv_skb+0x61/0xb2<br /> netlink_unicast+0x100/0x187<br /> netlink_sendmsg+0x37f/0x3a0<br /> ? netlink_unicast+0x187/0x187<br /> sock_sendmsg_nosec+0x67/0x9b<br /> ____sys_sendmsg+0x19d/0x1f9<br /> ? copy_msghdr_from_user+0x4c/0x5e<br /> ? rcu_read_lock_any_held+0x2a/0x78<br /> ___sys_sendmsg+0x6c/0x8c<br /> ? asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> ? lockdep_hardirqs_on+0xd9/0x102<br /> ? sockfd_lookup_light+0x69/0x99<br /> __sys_sendmsg+0x50/0x6e<br /> do_syscall_64+0xcb/0xf2<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f98dea28914<br /> Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53<br /> RSP: 002b:00007fff859f5e68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e2e<br /> RAX: ffffffffffffffda RBX: 00000000619cb810 RCX: 00007f98dea28914<br /> RDX: 0000000000000000 RSI: 00007fff859f5ed0 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000008<br /> R10: fffffffffffffce6 R11: 0000000000000246 R12: 0000000000000001<br /> R13: 000055c0097ae520 R14: 000055c0097957fd R15: 00007fff859f63a0<br /> <br /> Modules linked in: bridge stp llc bonding virtio_net

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: avoid bpf_prog refcount underflow<br /> <br /> Ice driver has the routines for managing XDP resources that are shared<br /> between ndo_bpf op and VSI rebuild flow. The latter takes place for<br /> example when user changes queue count on an interface via ethtool&amp;#39;s<br /> set_channels().<br /> <br /> There is an issue around the bpf_prog refcounting when VSI is being<br /> rebuilt - since ice_prepare_xdp_rings() is called with vsi-&gt;xdp_prog as<br /> an argument that is used later on by ice_vsi_assign_bpf_prog(), same<br /> bpf_prog pointers are swapped with each other. Then it is also<br /> interpreted as an &amp;#39;old_prog&amp;#39; which in turn causes us to call<br /> bpf_prog_put on it that will decrement its refcount.<br /> <br /> Below splat can be interpreted in a way that due to zero refcount of a<br /> bpf_prog it is wiped out from the system while kernel still tries to<br /> refer to it:<br /> <br /> [ 481.069429] BUG: unable to handle page fault for address: ffffc9000640f038<br /> [ 481.077390] #PF: supervisor read access in kernel mode<br /> [ 481.083335] #PF: error_code(0x0000) - not-present page<br /> [ 481.089276] PGD 100000067 P4D 100000067 PUD 1001cb067 PMD 106d2b067 PTE 0<br /> [ 481.097141] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 481.101980] CPU: 12 PID: 3339 Comm: sudo Tainted: G OE 5.15.0-rc5+ #1<br /> [ 481.110840] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016<br /> [ 481.122021] RIP: 0010:dev_xdp_prog_id+0x25/0x40<br /> [ 481.127265] Code: 80 00 00 00 00 0f 1f 44 00 00 89 f6 48 c1 e6 04 48 01 fe 48 8b 86 98 08 00 00 48 85 c0 74 13 48 8b 50 18 31 c0 48 85 d2 74 07 8b 42 38 8b 40 20 c3 48 8b 96 90 08 00 00 eb e8 66 2e 0f 1f 84<br /> [ 481.148991] RSP: 0018:ffffc90007b63868 EFLAGS: 00010286<br /> [ 481.155034] RAX: 0000000000000000 RBX: ffff889080824000 RCX: 0000000000000000<br /> [ 481.163278] RDX: ffffc9000640f000 RSI: ffff889080824010 RDI: ffff889080824000<br /> [ 481.171527] RBP: ffff888107af7d00 R08: 0000000000000000 R09: ffff88810db5f6e0<br /> [ 481.179776] R10: 0000000000000000 R11: ffff8890885b9988 R12: ffff88810db5f4bc<br /> [ 481.188026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> [ 481.196276] FS: 00007f5466d5bec0(0000) GS:ffff88903fb00000(0000) knlGS:0000000000000000<br /> [ 481.205633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 481.212279] CR2: ffffc9000640f038 CR3: 000000014429c006 CR4: 00000000003706e0<br /> [ 481.220530] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 481.228771] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 481.237029] Call Trace:<br /> [ 481.239856] rtnl_fill_ifinfo+0x768/0x12e0<br /> [ 481.244602] rtnl_dump_ifinfo+0x525/0x650<br /> [ 481.249246] ? __alloc_skb+0xa5/0x280<br /> [ 481.253484] netlink_dump+0x168/0x3c0<br /> [ 481.257725] netlink_recvmsg+0x21e/0x3e0<br /> [ 481.262263] ____sys_recvmsg+0x87/0x170<br /> [ 481.266707] ? __might_fault+0x20/0x30<br /> [ 481.271046] ? _copy_from_user+0x66/0xa0<br /> [ 481.275591] ? iovec_from_user+0xf6/0x1c0<br /> [ 481.280226] ___sys_recvmsg+0x82/0x100<br /> [ 481.284566] ? sock_sendmsg+0x5e/0x60<br /> [ 481.288791] ? __sys_sendto+0xee/0x150<br /> [ 481.293129] __sys_recvmsg+0x56/0xa0<br /> [ 481.297267] do_syscall_64+0x3b/0xc0<br /> [ 481.301395] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 481.307238] RIP: 0033:0x7f5466f39617<br /> [ 481.311373] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bd 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2f 00 00 00 0f 05 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10<br /> [ 481.342944] RSP: 002b:00007ffedc7f4308 EFLAGS: 00000246 ORIG_RAX: 000000000000002f<br /> [ 481.361783] RAX: ffffffffffffffda RBX: 00007ffedc7f5460 RCX: 00007f5466f39617<br /> [ 481.380278] RDX: 0000000000000000 RSI: 00007ffedc7f5360 RDI: 0000000000000003<br /> [ 481.398500] RBP: 00007ffedc7f53f0 R08: 0000000000000000 R09: 000055d556f04d50<br /> [ 481.416463] R10: 0000000000000077 R11: 0000000000000246 R12: 00007ffedc7f5360<br /> [ 481.434131] R13: 00007ffedc7f5350 R14: 00007ffedc7f5344 R15: 0000000000000e98<br /> [ 481.451520] Modules linked in: ice<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: marvell: prestera: fix double free issue on err path<br /> <br /> fix error path handling in prestera_bridge_port_join() that<br /> cases prestera driver to crash (see below).<br /> <br /> Trace:<br /> Internal error: Oops: 96000044 [#1] SMP<br /> Modules linked in: prestera_pci prestera uio_pdrv_genirq<br /> CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : prestera_bridge_destroy+0x2c/0xb0 [prestera]<br /> lr : prestera_bridge_port_join+0x2cc/0x350 [prestera]<br /> sp : ffff800011a1b0f0<br /> ...<br /> x2 : ffff000109ca6c80 x1 : dead000000000100 x0 : dead000000000122<br /> Call trace:<br /> prestera_bridge_destroy+0x2c/0xb0 [prestera]<br /> prestera_bridge_port_join+0x2cc/0x350 [prestera]<br /> prestera_netdev_port_event.constprop.0+0x3c4/0x450 [prestera]<br /> prestera_netdev_event_handler+0xf4/0x110 [prestera]<br /> raw_notifier_call_chain+0x54/0x80<br /> call_netdevice_notifiers_info+0x54/0xa0<br /> __netdev_upper_dev_link+0x19c/0x380

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Fix kernel panic during drive powercycle test<br /> <br /> While looping over shost&amp;#39;s sdev list it is possible that one<br /> of the drives is getting removed and its sas_target object is<br /> freed but its sdev object remains intact.<br /> <br /> Consequently, a kernel panic can occur while the driver is trying to access<br /> the sas_address field of sas_target object without also checking the<br /> sas_target object for NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> proc/vmcore: fix clearing user buffer by properly using clear_user()<br /> <br /> To clear a user buffer we cannot simply use memset, we have to use<br /> clear_user(). With a virtio-mem device that registers a vmcore_cb and<br /> has some logically unplugged memory inside an added Linux memory block,<br /> I can easily trigger a BUG by copying the vmcore via "cp":<br /> <br /> systemd[1]: Starting Kdump Vmcore Save Service...<br /> kdump[420]: Kdump is using the default log level(3).<br /> kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/<br /> kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/<br /> kdump[465]: saving vmcore-dmesg.txt complete<br /> kdump[467]: saving vmcore<br /> BUG: unable to handle page fault for address: 00007f2374e01000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0003) - permissions violation<br /> PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867<br /> Oops: 0003 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86<br /> Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81<br /> RSP: 0018:ffffc9000073be08 EFLAGS: 00010212<br /> RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000<br /> RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008<br /> RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50<br /> R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000<br /> R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8<br /> FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0<br /> Call Trace:<br /> read_vmcore+0x236/0x2c0<br /> proc_reg_read+0x55/0xa0<br /> vfs_read+0x95/0x190<br /> ksys_read+0x4f/0xc0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access<br /> Prevention (SMAP)", which is used to detect wrong access from the kernel<br /> to user buffers like this: SMAP triggers a permissions violation on<br /> wrong access. In the x86-64 variant of clear_user(), SMAP is properly<br /> handled via clac()+stac().<br /> <br /> To fix, properly use clear_user() when we&amp;#39;re dealing with a user buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/32: Fix hardlockup on vmap stack overflow<br /> <br /> Since the commit c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not<br /> activate MMU before reading task struct") a vmap stack overflow<br /> results in a hard lockup. This is because emergency_ctx is still<br /> addressed with its virtual address allthough data MMU is not active<br /> anymore at that time.<br /> <br /> Fix it by using a physical address instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/scs: Reset task stack state in bringup_cpu()<br /> <br /> To hot unplug a CPU, the idle task on that CPU calls a few layers of C<br /> code before finally leaving the kernel. When KASAN is in use, poisoned<br /> shadow is left around for each of the active stack frames, and when<br /> shadow call stacks are in use. When shadow call stacks (SCS) are in use<br /> the task&amp;#39;s saved SCS SP is left pointing at an arbitrary point within<br /> the task&amp;#39;s shadow call stack.<br /> <br /> When a CPU is offlined than onlined back into the kernel, this stale<br /> state can adversely affect execution. Stale KASAN shadow can alias new<br /> stackframes and result in bogus KASAN warnings. A stale SCS SP is<br /> effectively a memory leak, and prevents a portion of the shadow call<br /> stack being used. Across a number of hotplug cycles the idle task&amp;#39;s<br /> entire shadow call stack can become unusable.<br /> <br /> We previously fixed the KASAN issue in commit:<br /> <br /> e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug")<br /> <br /> ... by removing any stale KASAN stack poison immediately prior to<br /> onlining a CPU.<br /> <br /> Subsequently in commit:<br /> <br /> f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")<br /> <br /> ... the refactoring left the KASAN and SCS cleanup in one-time idle<br /> thread initialization code rather than something invoked prior to each<br /> CPU being onlined, breaking both as above.<br /> <br /> We fixed SCS (but not KASAN) in commit:<br /> <br /> 63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit")<br /> <br /> ... but as this runs in the context of the idle task being offlined it&amp;#39;s<br /> potentially fragile.<br /> <br /> To fix these consistently and more robustly, reset the SCS SP and KASAN<br /> shadow of a CPU&amp;#39;s idle task immediately before we online that CPU in<br /> bringup_cpu(). This ensures the idle task always has a consistent state<br /> when it is running, and removes the need to so so when exiting an idle<br /> task.<br /> <br /> Whenever any thread is created, dup_task_struct() will give the task a<br /> stack which is free of KASAN shadow, and initialize the task&amp;#39;s SCS SP,<br /> so there&amp;#39;s no need to specially initialize either for idle thread within<br /> init_idle(), as this was only necessary to handle hotplug cycles.<br /> <br /> I&amp;#39;ve tested this on arm64 with:<br /> <br /> * gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK<br /> * clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK<br /> <br /> ... offlining and onlining CPUS with:<br /> <br /> | while true; do<br /> | for C in /sys/devices/system/cpu/cpu*/online; do<br /> | echo 0 &gt; $C;<br /> | echo 1 &gt; $C;<br /> | done<br /> | done

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa_sim: avoid putting an uninitialized iova_domain<br /> <br /> The system will crash if we put an uninitialized iova_domain, this<br /> could happen when an error occurs before initializing the iova_domain<br /> in vdpasim_create().<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> RIP: 0010:__cpuhp_state_remove_instance+0x96/0x1c0<br /> ...<br /> Call Trace:<br /> <br /> put_iova_domain+0x29/0x220<br /> vdpasim_free+0xd1/0x120 [vdpa_sim]<br /> vdpa_release_dev+0x21/0x40 [vdpa]<br /> device_release+0x33/0x90<br /> kobject_release+0x63/0x160<br /> vdpasim_create+0x127/0x2a0 [vdpa_sim]<br /> vdpasim_net_dev_add+0x7d/0xfe [vdpa_sim_net]<br /> vdpa_nl_cmd_dev_add_set_doit+0xe1/0x1a0 [vdpa]<br /> genl_family_rcv_msg_doit+0x112/0x140<br /> genl_rcv_msg+0xdf/0x1d0<br /> ...<br /> <br /> So we must make sure the iova_domain is already initialized before<br /> put it.<br /> <br /> In addition, we may get the following warning in this case:<br /> WARNING: ... drivers/iommu/iova.c:344 iova_cache_put+0x58/0x70<br /> <br /> So we must make sure the iova_cache_put() is invoked only if the<br /> iova_cache_get() is already invoked. Let&amp;#39;s fix it together.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce()<br /> <br /> ethtool_set_coalesce() now uses both the .get_coalesce() and<br /> .set_coalesce() callbacks. But the check for their availability is<br /> buggy, so changing the coalesce settings on a device where the driver<br /> provides only _one_ of the callbacks results in a NULL pointer<br /> dereference instead of an -EOPNOTSUPP.<br /> <br /> Fix the condition so that the availability of both callbacks is<br /> ensured. This also matches the netlink code.<br /> <br /> Note that reproducing this requires some effort - it only affects the<br /> legacy ioctl path, and needs a specific combination of driver options:<br /> - have .get_coalesce() and .coalesce_supported but no<br /> .set_coalesce(), or<br /> - have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn&amp;#39;t<br /> cause the crash as it first attempts to call ethtool_get_coalesce()<br /> and bails out on error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_ets: don&amp;#39;t peek at classes beyond &amp;#39;nbands&amp;#39;<br /> <br /> when the number of DRR classes decreases, the round-robin active list can<br /> contain elements that have already been freed in ets_qdisc_change(). As a<br /> consequence, it&amp;#39;s possible to see a NULL dereference crash, caused by the<br /> attempt to call cl-&gt;qdisc-&gt;ops-&gt;peek(cl-&gt;qdisc) when cl-&gt;qdisc is NULL:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 910 Comm: mausezahn Not tainted 5.16.0-rc1+ #475<br /> Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014<br /> RIP: 0010:ets_qdisc_dequeue+0x129/0x2c0 [sch_ets]<br /> Code: c5 01 41 39 ad e4 02 00 00 0f 87 18 ff ff ff 49 8b 85 c0 02 00 00 49 39 c4 0f 84 ba 00 00 00 49 8b ad c0 02 00 00 48 8b 7d 10 8b 47 18 48 8b 40 38 0f ae e8 ff d0 48 89 c3 48 85 c0 0f 84 9d<br /> RSP: 0000:ffffbb36c0b5fdd8 EFLAGS: 00010287<br /> RAX: ffff956678efed30 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: ffffffff9b938dc9 RDI: 0000000000000000<br /> RBP: ffff956678efed30 R08: e2f3207fe360129c R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff956678efeac0<br /> R13: ffff956678efe800 R14: ffff956611545000 R15: ffff95667ac8f100<br /> FS: 00007f2aa9120740(0000) GS:ffff95667b800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000018 CR3: 000000011070c000 CR4: 0000000000350ee0<br /> Call Trace:<br /> <br /> qdisc_peek_dequeued+0x29/0x70 [sch_ets]<br /> tbf_dequeue+0x22/0x260 [sch_tbf]<br /> __qdisc_run+0x7f/0x630<br /> net_tx_action+0x290/0x4c0<br /> __do_softirq+0xee/0x4f8<br /> irq_exit_rcu+0xf4/0x130<br /> sysvec_apic_timer_interrupt+0x52/0xc0<br /> asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> RIP: 0033:0x7f2aa7fc9ad4<br /> Code: b9 ff ff 48 8b 54 24 18 48 83 c4 08 48 89 ee 48 89 df 5b 5d e9 ed fc ff ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 83 ec 10 48 8b 05 10 64 33 00 48 8b 00 48 85 c0 0f 85 84 00<br /> RSP: 002b:00007ffe5d33fab8 EFLAGS: 00000202<br /> RAX: 0000000000000002 RBX: 0000561f72c31460 RCX: 0000561f72c31720<br /> RDX: 0000000000000002 RSI: 0000561f72c31722 RDI: 0000561f72c31720<br /> RBP: 000000000000002a R08: 00007ffe5d33fa40 R09: 0000000000000014<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000561f7187e380<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000561f72c31460<br /> <br /> Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt intel_rapl_msr iTCO_vendor_support intel_rapl_common joydev virtio_balloon lpc_ich i2c_i801 i2c_smbus pcspkr ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel ahci libahci ghash_clmulni_intel serio_raw libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod<br /> CR2: 0000000000000018<br /> <br /> Ensuring that &amp;#39;alist&amp;#39; was never zeroed [1] was not sufficient, we need to<br /> remove from the active list those elements that are no more SP nor DRR.<br /> <br /> [1] https://lore.kernel.org/netdev/60d274838bf09777f0371253416e8af71360bc08.1633609148.git.dcaratti@redhat.com/<br /> <br /> v3: fix race between ets_qdisc_change() and ets_qdisc_dequeue() delisting<br /> DRR classes beyond &amp;#39;nbands&amp;#39; in ets_qdisc_change() with the qdisc lock<br /> acquired, thanks to Cong Wang.<br /> <br /> v2: when a NULL qdisc is found in the DRR active list, try to dequeue skb<br /> from the next list item.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: Disable Tx queues when reconfiguring the interface<br /> <br /> The Tx queues were not disabled in situations where the driver needed to<br /> stop the interface to apply a new configuration. This could result in a<br /> kernel panic when doing any of the 3 following actions:<br /> * reconfiguring the number of queues (ethtool -L)<br /> * reconfiguring the size of the ring buffers (ethtool -G)<br /> * installing/removing an XDP program (ip l set dev ethX xdp)<br /> <br /> Prevent the panic by making sure netif_tx_disable is called when stopping<br /> an interface.<br /> <br /> Without this patch, the following kernel panic can be observed when doing<br /> any of the actions above:<br /> <br /> Unable to handle kernel paging request at virtual address ffff80001238d040<br /> [....]<br /> Call trace:<br /> dwmac4_set_addr+0x8/0x10<br /> dev_hard_start_xmit+0xe4/0x1ac<br /> sch_direct_xmit+0xe8/0x39c<br /> __dev_queue_xmit+0x3ec/0xaf0<br /> dev_queue_xmit+0x14/0x20<br /> [...]<br /> [ end trace 0000000000000002 ]---