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-46951

Publication date:
27/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: efi: Use local variable for calculating final log size<br /> <br /> When tpm_read_log_efi is called multiple times, which happens when<br /> one loads and unloads a TPM2 driver multiple times, then the global<br /> variable efi_tpm_final_log_size will at some point become a negative<br /> number due to the subtraction of final_events_preboot_size occurring<br /> each time. Use a local variable to avoid this integer underflow.<br /> <br /> The following issue is now resolved:<br /> <br /> Mar 8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Mar 8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy]<br /> Mar 8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20<br /> Mar 8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4<br /> Mar 8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206<br /> Mar 8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f<br /> Mar 8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d<br /> Mar 8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073<br /> Mar 8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5<br /> Mar 8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018<br /> Mar 8 15:35:12 hibinst kernel: FS: 0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000<br /> Mar 8 15:35:12 hibinst kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> Mar 8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0<br /> Mar 8 15:35:12 hibinst kernel: Call Trace:<br /> Mar 8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7<br /> Mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0<br /> Mar 8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260<br /> Mar 8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy]<br /> Mar 8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370<br /> Mar 8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0<br /> Mar 8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370
Severity: Pending analysis
Last modification:
27/02/2024

CVE-2021-46954

Publication date:
27/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_frag: fix stack OOB read while fragmenting IPv4 packets<br /> <br /> when &amp;#39;act_mirred&amp;#39; tries to fragment IPv4 packets that had been previously<br /> re-assembled using &amp;#39;act_ct&amp;#39;, splats like the following can be observed on<br /> kernels built with KASAN:<br /> <br /> BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60<br /> Read of size 1 at addr ffff888147009574 by task ping/947<br /> <br /> CPU: 0 PID: 947 Comm: ping Not tainted 5.12.0-rc6+ #418<br /> Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack+0x92/0xc1<br /> print_address_description.constprop.7+0x1a/0x150<br /> kasan_report.cold.13+0x7f/0x111<br /> ip_do_fragment+0x1b03/0x1f60<br /> sch_fragment+0x4bf/0xe40<br /> tcf_mirred_act+0xc3d/0x11a0 [act_mirred]<br /> tcf_action_exec+0x104/0x3e0<br /> fl_classify+0x49a/0x5e0 [cls_flower]<br /> tcf_classify_ingress+0x18a/0x820<br /> __netif_receive_skb_core+0xae7/0x3340<br /> __netif_receive_skb_one_core+0xb6/0x1b0<br /> process_backlog+0x1ef/0x6c0<br /> __napi_poll+0xaa/0x500<br /> net_rx_action+0x702/0xac0<br /> __do_softirq+0x1e4/0x97f<br /> do_softirq+0x71/0x90<br /> <br /> __local_bh_enable_ip+0xdb/0xf0<br /> ip_finish_output2+0x760/0x2120<br /> ip_do_fragment+0x15a5/0x1f60<br /> __ip_finish_output+0x4c2/0xea0<br /> ip_output+0x1ca/0x4d0<br /> ip_send_skb+0x37/0xa0<br /> raw_sendmsg+0x1c4b/0x2d00<br /> sock_sendmsg+0xdb/0x110<br /> __sys_sendto+0x1d7/0x2b0<br /> __x64_sys_sendto+0xdd/0x1b0<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f82e13853eb<br /> Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89<br /> RSP: 002b:00007ffe01fad888 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00005571aac13700 RCX: 00007f82e13853eb<br /> RDX: 0000000000002330 RSI: 00005571aac13700 RDI: 0000000000000003<br /> RBP: 0000000000002330 R08: 00005571aac10500 R09: 0000000000000010<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe01faefb0<br /> R13: 00007ffe01fad890 R14: 00007ffe01fad980 R15: 00005571aac0f0a0<br /> <br /> The buggy address belongs to the page:<br /> page:000000001dff2e03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x147009<br /> flags: 0x17ffffc0001000(reserved)<br /> raw: 0017ffffc0001000 ffffea00051c0248 ffffea00051c0248 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888147009400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff888147009480: f1 f1 f1 f1 04 f2 f2 f2 f2 f2 f2 f2 00 00 00 00<br /> &gt;ffff888147009500: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2<br /> ^<br /> ffff888147009580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff888147009600: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2<br /> <br /> for IPv4 packets, sch_fragment() uses a temporary struct dst_entry. Then,<br /> in the following call graph:<br /> <br /> ip_do_fragment()<br /> ip_skb_dst_mtu()<br /> ip_dst_mtu_maybe_forward()<br /> ip_mtu_locked()<br /> <br /> the pointer to struct dst_entry is used as pointer to struct rtable: this<br /> turns the access to struct members like rt_mtu_locked into an OOB read in<br /> the stack. Fix this changing the temporary variable used for IPv4 packets<br /> in sch_fragment(), similarly to what is done for IPv6 few lines below.
Severity: Pending analysis
Last modification:
27/02/2024

CVE-2021-46955

Publication date:
27/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: fix stack OOB read while fragmenting IPv4 packets<br /> <br /> running openvswitch on kernels built with KASAN, it&amp;#39;s possible to see the<br /> following splat while testing fragmentation of IPv4 packets:<br /> <br /> BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60<br /> Read of size 1 at addr ffff888112fc713c by task handler2/1367<br /> <br /> CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418<br /> Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014<br /> Call Trace:<br /> dump_stack+0x92/0xc1<br /> print_address_description.constprop.7+0x1a/0x150<br /> kasan_report.cold.13+0x7f/0x111<br /> ip_do_fragment+0x1b03/0x1f60<br /> ovs_fragment+0x5bf/0x840 [openvswitch]<br /> do_execute_actions+0x1bd5/0x2400 [openvswitch]<br /> ovs_execute_actions+0xc8/0x3d0 [openvswitch]<br /> ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch]<br /> genl_family_rcv_msg_doit.isra.15+0x227/0x2d0<br /> genl_rcv_msg+0x287/0x490<br /> netlink_rcv_skb+0x120/0x380<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x439/0x630<br /> netlink_sendmsg+0x719/0xbf0<br /> sock_sendmsg+0xe2/0x110<br /> ____sys_sendmsg+0x5ba/0x890<br /> ___sys_sendmsg+0xe9/0x160<br /> __sys_sendmsg+0xd3/0x170<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f957079db07<br /> Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48<br /> RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07<br /> RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019<br /> RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730<br /> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000<br /> R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0<br /> <br /> The buggy address belongs to the page:<br /> page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7<br /> flags: 0x17ffffc0000000()<br /> raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame:<br /> ovs_fragment+0x0/0x840 [openvswitch]<br /> <br /> this frame has 2 objects:<br /> [32, 144) &amp;#39;ovs_dst&amp;#39;<br /> [192, 424) &amp;#39;ovs_rt&amp;#39;<br /> <br /> Memory state around the buggy address:<br /> ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00<br /> ^<br /> ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00<br /> <br /> for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then,<br /> in the following call graph:<br /> <br /> ip_do_fragment()<br /> ip_skb_dst_mtu()<br /> ip_dst_mtu_maybe_forward()<br /> ip_mtu_locked()<br /> <br /> the pointer to struct dst_entry is used as pointer to struct rtable: this<br /> turns the access to struct members like rt_mtu_locked into an OOB read in<br /> the stack. Fix this changing the temporary variable used for IPv4 packets<br /> in ovs_fragment(), similarly to what is done for IPv6 few lines below.
Severity: Pending analysis
Last modification:
27/02/2024

CVE-2021-46957

Publication date:
27/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv/kprobe: fix kernel panic when invoking sys_read traced by kprobe<br /> <br /> The execution of sys_read end up hitting a BUG_ON() in __find_get_block<br /> after installing kprobe at sys_read, the BUG message like the following:<br /> <br /> [ 65.708663] ------------[ cut here ]------------<br /> [ 65.709987] kernel BUG at fs/buffer.c:1251!<br /> [ 65.711283] Kernel BUG [#1]<br /> [ 65.712032] Modules linked in:<br /> [ 65.712925] CPU: 0 PID: 51 Comm: sh Not tainted 5.12.0-rc4 #1<br /> [ 65.714407] Hardware name: riscv-virtio,qemu (DT)<br /> [ 65.715696] epc : __find_get_block+0x218/0x2c8<br /> [ 65.716835] ra : __getblk_gfp+0x1c/0x4a<br /> [ 65.717831] epc : ffffffe00019f11e ra : ffffffe00019f56a sp : ffffffe002437930<br /> [ 65.719553] gp : ffffffe000f06030 tp : ffffffe0015abc00 t0 : ffffffe00191e038<br /> [ 65.721290] t1 : ffffffe00191e038 t2 : 000000000000000a s0 : ffffffe002437960<br /> [ 65.723051] s1 : ffffffe00160ad00 a0 : ffffffe00160ad00 a1 : 000000000000012a<br /> [ 65.724772] a2 : 0000000000000400 a3 : 0000000000000008 a4 : 0000000000000040<br /> [ 65.726545] a5 : 0000000000000000 a6 : ffffffe00191e000 a7 : 0000000000000000<br /> [ 65.728308] s2 : 000000000000012a s3 : 0000000000000400 s4 : 0000000000000008<br /> [ 65.730049] s5 : 000000000000006c s6 : ffffffe00240f800 s7 : ffffffe000f080a8<br /> [ 65.731802] s8 : 0000000000000001 s9 : 000000000000012a s10: 0000000000000008<br /> [ 65.733516] s11: 0000000000000008 t3 : 00000000000003ff t4 : 000000000000000f<br /> [ 65.734434] t5 : 00000000000003ff t6 : 0000000000040000<br /> [ 65.734613] status: 0000000000000100 badaddr: 0000000000000000 cause: 0000000000000003<br /> [ 65.734901] Call Trace:<br /> [ 65.735076] [] __find_get_block+0x218/0x2c8<br /> [ 65.735417] [] __ext4_get_inode_loc+0xb2/0x2f6<br /> [ 65.735618] [] ext4_get_inode_loc+0x3a/0x8a<br /> [ 65.735802] [] ext4_reserve_inode_write+0x2e/0x8c<br /> [ 65.735999] [] __ext4_mark_inode_dirty+0x4c/0x18e<br /> [ 65.736208] [] ext4_dirty_inode+0x46/0x66<br /> [ 65.736387] [] __mark_inode_dirty+0x12c/0x3da<br /> [ 65.736576] [] touch_atime+0x146/0x150<br /> [ 65.736748] [] filemap_read+0x234/0x246<br /> [ 65.736920] [] generic_file_read_iter+0xc0/0x114<br /> [ 65.737114] [] ext4_file_read_iter+0x42/0xea<br /> [ 65.737310] [] new_sync_read+0xe2/0x15a<br /> [ 65.737483] [] vfs_read+0xca/0xf2<br /> [ 65.737641] [] ksys_read+0x5e/0xc8<br /> [ 65.737816] [] sys_read+0xe/0x16<br /> [ 65.737973] [] ret_from_syscall+0x0/0x2<br /> [ 65.738858] ---[ end trace fe93f985456c935d ]---<br /> <br /> A simple reproducer looks like:<br /> echo &amp;#39;p:myprobe sys_read fd=%a0 buf=%a1 count=%a2&amp;#39; &gt; /sys/kernel/debug/tracing/kprobe_events<br /> echo 1 &gt; /sys/kernel/debug/tracing/events/kprobes/myprobe/enable<br /> cat /sys/kernel/debug/tracing/trace<br /> <br /> Here&amp;#39;s what happens to hit that BUG_ON():<br /> <br /> 1) After installing kprobe at entry of sys_read, the first instruction<br /> is replaced by &amp;#39;ebreak&amp;#39; instruction on riscv64 platform.<br /> <br /> 2) Once kernel reach the &amp;#39;ebreak&amp;#39; instruction at the entry of sys_read,<br /> it trap into the riscv breakpoint handler, where it do something to<br /> setup for coming single-step of origin instruction, including backup<br /> the &amp;#39;sstatus&amp;#39; in pt_regs, followed by disable interrupt during single<br /> stepping via clear &amp;#39;SIE&amp;#39; bit of &amp;#39;sstatus&amp;#39; in pt_regs.<br /> <br /> 3) Then kernel restore to the instruction slot contains two instructions,<br /> one is original instruction at entry of sys_read, the other is &amp;#39;ebreak&amp;#39;.<br /> Here it trigger a &amp;#39;Instruction page fault&amp;#39; exception (value at &amp;#39;scause&amp;#39;<br /> is &amp;#39;0xc&amp;#39;), if PF is not filled into PageTabe for that slot yet.<br /> <br /> 4) Again kernel trap into page fault exception handler, where it choose<br /> different policy according to the state of running kprobe. Because<br /> afte 2) the state is KPROBE_HIT_SS, so kernel reset the current kp<br /> ---truncated---
Severity: Pending analysis
Last modification:
27/02/2024

CVE-2021-46958

Publication date:
27/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race between transaction aborts and fsyncs leading to use-after-free<br /> <br /> There is a race between a task aborting a transaction during a commit,<br /> a task doing an fsync and the transaction kthread, which leads to an<br /> use-after-free of the log root tree. When this happens, it results in a<br /> stack trace like the following:<br /> <br /> BTRFS info (device dm-0): forced readonly<br /> BTRFS warning (device dm-0): Skipping commit of aborted transaction.<br /> BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure<br /> BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5)<br /> BTRFS warning (device dm-0): Skipping commit of aborted transaction.<br /> BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10<br /> BTRFS error (device dm-0): error writing primary super block to device 1<br /> BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10<br /> BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10<br /> BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10<br /> BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers)<br /> BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure<br /> general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI<br /> CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__mutex_lock+0x139/0xa40<br /> Code: c0 74 19 (...)<br /> RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202<br /> RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002<br /> RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040<br /> R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358<br /> FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ? __btrfs_handle_fs_error+0xde/0x146 [btrfs]<br /> ? btrfs_sync_log+0x7c1/0xf20 [btrfs]<br /> ? btrfs_sync_log+0x7c1/0xf20 [btrfs]<br /> btrfs_sync_log+0x7c1/0xf20 [btrfs]<br /> btrfs_sync_file+0x40c/0x580 [btrfs]<br /> do_fsync+0x38/0x70<br /> __x64_sys_fsync+0x10/0x20<br /> do_syscall_64+0x33/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7fa9142a55c3<br /> Code: 8b 15 09 (...)<br /> RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a<br /> RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3<br /> RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005<br /> RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340<br /> R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0<br /> Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...)<br /> ---[ end trace ee2f1b19327d791d ]---<br /> <br /> The steps that lead to this crash are the following:<br /> <br /> 1) We are at transaction N;<br /> <br /> 2) We have two tasks with a transaction handle attached to transaction N.<br /> Task A and Task B. Task B is doing an fsync;<br /> <br /> 3) Task B is at btrfs_sync_log(), and has saved fs_info-&gt;log_root_tree<br /> into a local variable named &amp;#39;log_root_tree&amp;#39; at the top of<br /> btrfs_sync_log(). Task B is about to call write_all_supers(), but<br /> before that...<br /> <br /> 4) Task A calls btrfs_commit_transaction(), and after it sets the<br /> transaction state to TRANS_STATE_COMMIT_START, an error happens before<br /> it w<br /> ---truncated---
Severity: Pending analysis
Last modification:
27/02/2024

botón arriba