Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las ultimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las ultimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (https://nvd.nist.gov/) (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (https://cve.mitre.org/) (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS (https://www.incibe.es/feed/vulnerabilities) o Boletines (https://www.incibe.es/incibe/suscripciones) podemos estar informados diariamente de las ultimas vulnerabilidades incorporadas al repositorio.

CVE-2021-47563

Fecha de publicación:
24/05/2024
Idioma:
Inglés
*** Pendiente de traducción *** 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---
Severidad: Pendiente de análisis
Última modificación:
24/05/2024

CVE-2021-47566

Fecha de publicación:
24/05/2024
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Severidad: Pendiente de análisis
Última modificación:
24/05/2024

CVE-2021-47552

Fecha de publicación:
24/05/2024
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()<br /> <br /> For avoiding to slow down queue destroy, we don&amp;#39;t call<br /> blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to<br /> cancel dispatch work in blk_release_queue().<br /> <br /> However, this way has caused kernel oops[1], reported by Changhui. The log<br /> shows that scsi_device can be freed before running blk_release_queue(),<br /> which is expected too since scsi_device is released after the scsi disk<br /> is closed and the scsi_device is removed.<br /> <br /> Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue()<br /> and disk_release():<br /> <br /> 1) when disk_release() is run, the disk has been closed, and any sync<br /> dispatch activities have been done, so canceling dispatch work is enough to<br /> quiesce filesystem I/O dispatch activity.<br /> <br /> 2) in blk_cleanup_queue(), we only focus on passthrough request, and<br /> passthrough request is always explicitly allocated &amp; freed by<br /> its caller, so once queue is frozen, all sync dispatch activity<br /> for passthrough request has been done, then it is enough to just cancel<br /> dispatch work for avoiding any dispatch activity.<br /> <br /> [1] kernel panic log<br /> [12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300<br /> [12622.777186] #PF: supervisor read access in kernel mode<br /> [12622.782918] #PF: error_code(0x0000) - not-present page<br /> [12622.788649] PGD 0 P4D 0<br /> [12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1<br /> [12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015<br /> [12622.813321] Workqueue: kblockd blk_mq_run_work_fn<br /> [12622.818572] RIP: 0010:sbitmap_get+0x75/0x190<br /> [12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58<br /> [12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202<br /> [12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004<br /> [12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030<br /> [12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334<br /> [12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000<br /> [12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030<br /> [12622.889926] FS: 0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000<br /> [12622.898956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0<br /> [12622.913328] Call Trace:<br /> [12622.916055] <br /> [12622.918394] scsi_mq_get_budget+0x1a/0x110<br /> [12622.922969] __blk_mq_do_dispatch_sched+0x1d4/0x320<br /> [12622.928404] ? pick_next_task_fair+0x39/0x390<br /> [12622.933268] __blk_mq_sched_dispatch_requests+0xf4/0x140<br /> [12622.939194] blk_mq_sched_dispatch_requests+0x30/0x60<br /> [12622.944829] __blk_mq_run_hw_queue+0x30/0xa0<br /> [12622.949593] process_one_work+0x1e8/0x3c0<br /> [12622.954059] worker_thread+0x50/0x3b0<br /> [12622.958144] ? rescuer_thread+0x370/0x370<br /> [12622.962616] kthread+0x158/0x180<br /> [12622.966218] ? set_kthread_struct+0x40/0x40<br /> [12622.970884] ret_from_fork+0x22/0x30<br /> [12622.974875] <br /> [12622.977309] Modules linked in: scsi_debug rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs sunrpc dm_multipath intel_rapl_msr intel_rapl_common dell_wmi_descriptor sb_edac rfkill video x86_pkg_temp_thermal intel_powerclamp dcdbas coretemp kvm_intel kvm mgag200 irqbypass i2c_algo_bit rapl drm_kms_helper ipmi_ssif intel_cstate intel_uncore syscopyarea sysfillrect sysimgblt fb_sys_fops pcspkr cec mei_me lpc_ich mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter drm fuse xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg ixgbe ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata megaraid_sas ghash_clmulni_intel tg3 wdat_w<br /> ---truncated---
Severidad: Pendiente de análisis
Última modificación:
24/05/2024

CVE-2021-47553

Fecha de publicación:
24/05/2024
Idioma:
Inglés
*** Pendiente de traducción *** 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
Severidad: Pendiente de análisis
Última modificación:
24/05/2024

CVE-2021-47557

Fecha de publicación:
24/05/2024
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Severidad: Pendiente de análisis
Última modificación:
24/05/2024