Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: adjust efx-&gt;xdp_tx_queue_count with the real number of initialized queues<br /> <br /> efx-&gt;xdp_tx_queue_count is initially initialized to num_possible_cpus() and is<br /> later used to allocate and traverse efx-&gt;xdp_tx_queues lookup array. However,<br /> we may end up not initializing all the array slots with real queues during<br /> probing. This results, for example, in a NULL pointer dereference, when running<br /> "# ethtool -S ", similar to below<br /> <br /> [2570283.664955][T4126959] BUG: kernel NULL pointer dereference, address: 00000000000000f8<br /> [2570283.681283][T4126959] #PF: supervisor read access in kernel mode<br /> [2570283.695678][T4126959] #PF: error_code(0x0000) - not-present page<br /> [2570283.710013][T4126959] PGD 0 P4D 0<br /> [2570283.721649][T4126959] Oops: 0000 [#1] SMP PTI<br /> [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comm: ethtool Tainted: G O 5.10.20-cloudflare-2021.3.1 #1<br /> [2570283.752641][T4126959] Hardware name: <br /> [2570283.781408][T4126959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc]<br /> [2570283.796073][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b<br /> [2570283.831259][T4126959] RSP: 0018:ffffb79a77657ce8 EFLAGS: 00010202<br /> [2570283.845121][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018<br /> [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd970ce000 RDI: 0000000000000005<br /> [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f<br /> [2570283.892014][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8<br /> [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66c<br /> [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:0000000000000000<br /> [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [2570283.952524][T4126959] CR2: 00000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706e0<br /> [2570283.967529][T4126959] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [2570283.997308][T4126959] PKRU: 55555554<br /> [2570284.007649][T4126959] Call Trace:<br /> [2570284.017598][T4126959] dev_ethtool+0x1832/0x2830<br /> <br /> Fix this by adjusting efx-&gt;xdp_tx_queue_count after probing to reflect the true<br /> value of initialized slots in efx-&gt;xdp_tx_queues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: farch: fix TX queue lookup in TX event handling<br /> <br /> We&amp;#39;re starting from a TXQ label, not a TXQ type, so<br /> efx_channel_get_tx_queue() is inappropriate (and could return NULL,<br /> leading to panics).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: farch: fix TX queue lookup in TX flush done handling<br /> <br /> We&amp;#39;re starting from a TXQ instance number (&amp;#39;qid&amp;#39;), not a TXQ type, so<br /> efx_get_tx_queue() is inappropriate (and could return NULL, leading<br /> to panics).

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds<br /> <br /> Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused<br /> by a garbage timeout (retrans) mount option being passed to nfs mount,<br /> in this case from syzkaller.<br /> <br /> If the protocol is XPRT_TRANSPORT_UDP, then &amp;#39;retrans&amp;#39; is a shift<br /> value for a 64-bit long integer, so &amp;#39;retrans&amp;#39; cannot be &gt;= 64.<br /> If it is &gt;= 64, fail the mount and return an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: GTDT: Don&amp;#39;t corrupt interrupt mappings on watchdow probe failure<br /> <br /> When failing the driver probe because of invalid firmware properties,<br /> the GTDT driver unmaps the interrupt that it mapped earlier.<br /> <br /> However, it never checks whether the mapping of the interrupt actially<br /> succeeded. Even more, should the firmware report an illegal interrupt<br /> number that overlaps with the GIC SGI range, this can result in an<br /> IPI being unmapped, and subsequent fireworks (as reported by Dann<br /> Frazier).<br /> <br /> Rework the driver to have a slightly saner behaviour and actually<br /> check whether the interrupt has been mapped before unmapping things.

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtiofs: fix memory leak in virtio_fs_probe()<br /> <br /> When accidentally passing twice the same tag to qemu, kmemleak ended up<br /> reporting a memory leak in virtiofs. Also, looking at the log I saw the<br /> following error (that&amp;#39;s when I realised the duplicated tag):<br /> <br /> virtiofs: probe of virtio5 failed with error -17<br /> <br /> Here&amp;#39;s the kmemleak log for reference:<br /> <br /> unreferenced object 0xffff888103d47800 (size 1024):<br /> comm "systemd-udevd", pid 118, jiffies 4294893780 (age 18.340s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> ff ff ff ff ff ff ff ff 80 90 02 a0 ff ff ff ff ................<br /> backtrace:<br /> [] virtio_fs_probe+0x171/0x7ae [virtiofs]<br /> [] virtio_dev_probe+0x15f/0x210<br /> [] really_probe+0xea/0x430<br /> [] device_driver_attach+0xa8/0xb0<br /> [] __driver_attach+0x98/0x140<br /> [] bus_for_each_dev+0x7b/0xc0<br /> [] bus_add_driver+0x11b/0x1f0<br /> [] driver_register+0x8f/0xe0<br /> [] 0xffffffffa002c013<br /> [] do_one_initcall+0x64/0x2e0<br /> [] do_init_module+0x5c/0x260<br /> [] __do_sys_finit_module+0xb5/0x120<br /> [] do_syscall_64+0x33/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Return correct error code from smb2_get_enc_key<br /> <br /> Avoid a warning if the error percolates back up:<br /> <br /> [440700.376476] CIFS VFS: \\otters.example.com crypt_message: Could not get encryption key<br /> [440700.386947] ------------[ cut here ]------------<br /> [440700.386948] err = 1<br /> [440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70<br /> ...<br /> [440700.397304] CPU: 11 PID: 2733 Comm: tar Tainted: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu<br /> ...<br /> [440700.397334] Call Trace:<br /> [440700.397346] __filemap_set_wb_err+0x1a/0x70<br /> [440700.397419] cifs_writepages+0x9c7/0xb30 [cifs]<br /> [440700.397426] do_writepages+0x4b/0xe0<br /> [440700.397444] __filemap_fdatawrite_range+0xcb/0x100<br /> [440700.397455] filemap_write_and_wait+0x42/0xa0<br /> [440700.397486] cifs_setattr+0x68b/0xf30 [cifs]<br /> [440700.397493] notify_change+0x358/0x4a0<br /> [440700.397500] utimes_common+0xe9/0x1c0<br /> [440700.397510] do_utimes+0xc5/0x150<br /> [440700.397520] __x64_sys_utimensat+0x88/0xd0