Vulnerabilities

With the aim of informing, warning and helping professionals with the latest security vulnerabilities in technology systems, we have made a database available for users interested in this information, which is in Spanish and includes all of the latest documented and recognised vulnerabilities.

This repository, with over 75,000 registers, is based on the information from the NVD (http://nvd.nist.gov/) (National Vulnerability Database) – by virtue of a partnership agreement – through which INCIBE translates the included information into Spanish.

On occasions this list will show vulnerabilities that have still not been translated, as they are added while the INCIBE team is still carrying out the translation process. The CVE (Common Vulnerabilities and Exposures) Standard for Information Security Vulnerability Names is used (http://cve.mitre.org/) with the aim to support the exchange of information between different tools and databases.

All vulnerabilities collected are linked to different information sources, as well as available patches or solutions provided by manufacturers and developers. It is possible to carry out advanced searches, as there is the option to select different criteria to narrow down the results, some examples being vulnerability types, manufacturers and impact levels, among others.

Through RSS feeds (https://www.incibe.es/enfeed/vulnerabilities) or Newsletters (https://www.incibe.es/encert/simplenews/subscriptions/landing) we can be informed daily about the latest vulnerabilities added to the repository. Below there is a list, updated daily, where you can discover the latest vulnerabilities.

CVE-2021-47572

Publication date:
24/05/2024
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
Severity: Pending analysis
Last modification:
24/05/2024

CVE-2021-47563

Publication date:
24/05/2024
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---
Severity: Pending analysis
Last modification:
24/05/2024

CVE-2021-47566

Publication date:
24/05/2024
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.
Severity: Pending analysis
Last modification:
24/05/2024

CVE-2021-47552

Publication date:
24/05/2024
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---
Severity: Pending analysis
Last modification:
24/05/2024

CVE-2021-47553

Publication date:
24/05/2024
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
Severity: Pending analysis
Last modification:
24/05/2024