Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: strset: fix message length calculation<br /> <br /> Outer nest for ETHTOOL_A_STRSET_STRINGSETS is not accounted for.<br /> This may result in ETHTOOL_MSG_STRSET_GET producing a warning like:<br /> <br /> calculated message payload length (684) not sufficient<br /> WARNING: CPU: 0 PID: 30967 at net/ethtool/netlink.c:369 ethnl_default_doit+0x87a/0xa20<br /> <br /> and a splat.<br /> <br /> As usually with such warnings three conditions must be met for the warning<br /> to trigger:<br /> - there must be no skb size rounding up (e.g. reply_size of 684);<br /> - string set must be per-device (so that the header gets populated);<br /> - the device name must be at least 12 characters long.<br /> <br /> all in all with current user space it looks like reading priv flags<br /> is the only place this could potentially happen. Or with syzbot :)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix soft lookup in subflow_error_report()<br /> <br /> Maxim reported a soft lookup in subflow_error_report():<br /> <br /> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]<br /> RIP: 0010:native_queued_spin_lock_slowpath<br /> RSP: 0018:ffffa859c0003bc0 EFLAGS: 00000202<br /> RAX: 0000000000000101 RBX: 0000000000000001 RCX: 0000000000000000<br /> RDX: ffff9195c2772d88 RSI: 0000000000000000 RDI: ffff9195c2772d88<br /> RBP: ffff9195c2772d00 R08: 00000000000067b0 R09: c6e31da9eb1e44f4<br /> R10: ffff9195ef379700 R11: ffff9195edb50710 R12: ffff9195c2772d88<br /> R13: ffff9195f500e3d0 R14: ffff9195ef379700 R15: ffff9195ef379700<br /> FS: 0000000000000000(0000) GS:ffff91961f400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000c000407000 CR3: 0000000002988000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> _raw_spin_lock_bh<br /> subflow_error_report<br /> mptcp_subflow_data_available<br /> __mptcp_move_skbs_from_subflow<br /> mptcp_data_ready<br /> tcp_data_queue<br /> tcp_rcv_established<br /> tcp_v4_do_rcv<br /> tcp_v4_rcv<br /> ip_protocol_deliver_rcu<br /> ip_local_deliver_finish<br /> __netif_receive_skb_one_core<br /> netif_receive_skb<br /> rtl8139_poll 8139too<br /> __napi_poll<br /> net_rx_action<br /> __do_softirq<br /> __irq_exit_rcu<br /> common_interrupt<br /> <br /> <br /> The calling function - mptcp_subflow_data_available() - can be invoked<br /> from different contexts:<br /> - plain ssk socket lock<br /> - ssk socket lock + mptcp_data_lock<br /> - ssk socket lock + mptcp_data_lock + msk socket lock.<br /> <br /> Since subflow_error_report() tries to acquire the mptcp_data_lock, the<br /> latter two call chains will cause soft lookup.<br /> <br /> This change addresses the issue moving the error reporting call to<br /> outer functions, where the held locks list is known and the we can<br /> acquire only the needed one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sch_cake: Fix out of bounds when parsing TCP options and header<br /> <br /> The TCP option parser in cake qdisc (cake_get_tcpopt and<br /> cake_tcph_may_drop) could read one byte out of bounds. When the length<br /> is 1, the execution flow gets into the loop, reads one byte of the<br /> opcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads<br /> one more byte, which exceeds the length of 1.<br /> <br /> This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack<br /> out of bounds when parsing TCP options.").<br /> <br /> v2 changes:<br /> <br /> Added doff validation in cake_get_tcphdr to avoid parsing garbage as TCP<br /> header. Although it wasn&amp;#39;t strictly an out-of-bounds access (memory was<br /> allocated), garbage values could be read where CAKE expected the TCP<br /> header if doff was smaller than 5.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: Fix out of bounds when parsing TCP options<br /> <br /> The TCP option parser in mptcp (mptcp_get_options) could read one byte<br /> out of bounds. When the length is 1, the execution flow gets into the<br /> loop, reads one byte of the opcode, and if the opcode is neither<br /> TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the<br /> length of 1.<br /> <br /> This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack<br /> out of bounds when parsing TCP options.").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: synproxy: Fix out of bounds when parsing TCP options<br /> <br /> The TCP option parser in synproxy (synproxy_parse_options) could read<br /> one byte out of bounds. When the length is 1, the execution flow gets<br /> into the loop, reads one byte of the opcode, and if the opcode is<br /> neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds<br /> the length of 1.<br /> <br /> This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack<br /> out of bounds when parsing TCP options.").<br /> <br /> v2 changes:<br /> <br /> Added an early return when length

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix page reclaim for dead peer hairpin<br /> <br /> When adding a hairpin flow, a firmware-side send queue is created for<br /> the peer net device, which claims some host memory pages for its<br /> internal ring buffer. If the peer net device is removed/unbound before<br /> the hairpin flow is deleted, then the send queue is not destroyed which<br /> leads to a stack trace on pci device remove:<br /> <br /> [ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): MANAGE_PAGES(0x108) timeout. Will cause a leak of a command resource<br /> [ 748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): failed reclaiming pages: err -110<br /> [ 748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): failed reclaiming pages (-110) for func id 0x0<br /> [ 748.002171] ------------[ cut here ]------------<br /> [ 748.001177] FW pages counter is 4 after reclaiming all pages<br /> [ 748.001186] WARNING: CPU: 1 PID: 12985 at drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ +0.002771] Modules linked in: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [last unloaded: pps_core]<br /> [ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1<br /> [ 748.001376] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core]<br /> [ 748.001679] Code: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9<br /> [ 748.003781] RSP: 0018:ffff88815220faf8 EFLAGS: 00010286<br /> [ 748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000<br /> [ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102a441f51<br /> [ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8<br /> [ 748.001446] R10: ffff8882a50af73b R11: ffffed1054a15ee7 R12: fffffbfff07c1e30<br /> [ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000<br /> [ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) knlGS:0000000000000000<br /> [ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4: 0000000000370ea0<br /> [ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 748.001654] Call Trace:<br /> [ 748.000576] ? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core]<br /> [ 748.001416] ? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core]<br /> [ 748.001354] ? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core]<br /> [ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core]<br /> [ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core]<br /> [ 748.001200] remove_one+0x5f/0xc0 [mlx5_core]<br /> [ 748.001075] pci_device_remove+0x9f/0x1d0<br /> [ 748.000833] device_release_driver_internal+0x1e0/0x490<br /> [ 748.001207] unbind_store+0x19f/0x200<br /> [ 748.000942] ? sysfs_file_ops+0x170/0x170<br /> [ 748.001000] kernfs_fop_write_iter+0x2bc/0x450<br /> [ 748.000970] new_sync_write+0x373/0x610<br /> [ 748.001124] ? new_sync_read+0x600/0x600<br /> [ 748.001057] ? lock_acquire+0x4d6/0x700<br /> [ 748.000908] ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> [ 748.001126] ? fd_install+0x1c9/0x4d0<br /> [ 748.000951] vfs_write+0x4d0/0x800<br /> [ 748.000804] ksys_write+0xf9/0x1d0<br /> [ 748.000868] ? __x64_sys_read+0xb0/0xb0<br /> [ 748.000811] ? filp_open+0x50/0x50<br /> [ 748.000919] ? syscall_enter_from_user_mode+0x1d/0x50<br /> [ 748.001223] do_syscall_64+0x3f/0x80<br /> [ 748.000892] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 748.00<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: fix race between close() and udp_abort()<br /> <br /> Kaustubh reported and diagnosed a panic in udp_lib_lookup().<br /> The root cause is udp_abort() racing with close(). Both<br /> racing functions acquire the socket lock, but udp{v6}_destroy_sock()<br /> release it before performing destructive actions.<br /> <br /> We can&amp;#39;t easily extend the socket lock scope to avoid the race,<br /> instead use the SOCK_DEAD flag to prevent udp_abort from doing<br /> any action when the critical race happens.<br /> <br /> Diagnosed-and-tested-by: Kaustubh Pandey

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rds: fix memory leak in rds_recvmsg<br /> <br /> Syzbot reported memory leak in rds. The problem<br /> was in unputted refcount in case of error.<br /> <br /> int rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,<br /> int msg_flags)<br /> {<br /> ...<br /> <br /> if (!rds_next_incoming(rs, &amp;inc)) {<br /> ...<br /> }<br /> <br /> After this "if" inc refcount incremented and<br /> <br /> if (rds_cmsg_recv(inc, msg, rs)) {<br /> ret = -EFAULT;<br /> goto out;<br /> }<br /> ...<br /> out:<br /> return ret;<br /> }<br /> <br /> in case of rds_cmsg_recv() fail the refcount won&amp;#39;t be<br /> decremented. And it&amp;#39;s easy to see from ftrace log, that<br /> rds_inc_addref() don&amp;#39;t have rds_inc_put() pair in<br /> rds_recvmsg() after rds_cmsg_recv()<br /> <br /> 1) | rds_recvmsg() {<br /> 1) 3.721 us | rds_inc_addref();<br /> 1) 3.853 us | rds_message_inc_copy_to_user();<br /> 1) + 10.395 us | rds_cmsg_recv();<br /> 1) + 34.260 us | }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: fix memory leak in netlbl_cipsov4_add_std<br /> <br /> Reported by syzkaller:<br /> BUG: memory leak<br /> unreferenced object 0xffff888105df7000 (size 64):<br /> comm "syz-executor842", pid 360, jiffies 4294824824 (age 22.546s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc include/linux/slab.h:590 [inline]<br /> [] kzalloc include/linux/slab.h:720 [inline]<br /> [] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [inline]<br /> [] netlbl_cipsov4_add+0x390/0x2340 net/netlabel/netlabel_cipso_v4.c:416<br /> [] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739<br /> [] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]<br /> [] genl_rcv_msg+0x2bf/0x4f0 net/netlink/genetlink.c:800<br /> [] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504<br /> [] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811<br /> [] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]<br /> [] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340<br /> [] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929<br /> [] sock_sendmsg_nosec net/socket.c:654 [inline]<br /> [] sock_sendmsg+0x139/0x170 net/socket.c:674<br /> [] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350<br /> [] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404<br /> [] __sys_sendmsg+0xd3/0x190 net/socket.c:2433<br /> [] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The memory of doi_def-&gt;map.std pointing is allocated in<br /> netlbl_cipsov4_add_std, but no place has freed it. It should be<br /> freed in cipso_v4_doi_free which frees the cipso DOI resource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix use-after-free of encap entry in neigh update handler<br /> <br /> Function mlx5e_rep_neigh_update() wasn&amp;#39;t updated to accommodate rtnl lock<br /> removal from TC filter update path and properly handle concurrent encap<br /> entry insertion/deletion which can lead to following use-after-free:<br /> <br /> [23827.464923] ==================================================================<br /> [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]<br /> [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635<br /> [23827.472251]<br /> [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5<br /> [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]<br /> [23827.476731] Call Trace:<br /> [23827.477260] dump_stack+0xbb/0x107<br /> [23827.477906] print_address_description.constprop.0+0x18/0x140<br /> [23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]<br /> [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]<br /> [23827.480905] kasan_report.cold+0x7c/0xd8<br /> [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]<br /> [23827.482744] kasan_check_range+0x145/0x1a0<br /> [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core]<br /> [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core]<br /> [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core]<br /> [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core]<br /> [23827.497486] ? read_word_at_a_time+0xe/0x20<br /> [23827.498250] ? strscpy+0xa0/0x2a0<br /> [23827.498889] process_one_work+0x8ac/0x14e0<br /> [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> [23827.500537] ? pwq_dec_nr_in_flight+0x2c0/0x2c0<br /> [23827.501359] ? rwlock_bug.part.0+0x90/0x90<br /> [23827.502116] worker_thread+0x53b/0x1220<br /> [23827.502831] ? process_one_work+0x14e0/0x14e0<br /> [23827.503627] kthread+0x328/0x3f0<br /> [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40<br /> [23827.505065] ? __kthread_bind_mask+0x90/0x90<br /> [23827.505912] ret_from_fork+0x1f/0x30<br /> [23827.506621]<br /> [23827.506987] Allocated by task 28248:<br /> [23827.507694] kasan_save_stack+0x1b/0x40<br /> [23827.508476] __kasan_kmalloc+0x7c/0x90<br /> [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core]<br /> [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core]<br /> [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core]<br /> [23827.512234] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core]<br /> [23827.513298] tc_setup_cb_add+0x1d5/0x420<br /> [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower]<br /> [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower]<br /> [23827.515821] tc_new_tfilter+0x89a/0x2070<br /> [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0<br /> [23827.517300] netlink_rcv_skb+0x11d/0x340<br /> [23827.518021] netlink_unicast+0x42b/0x700<br /> [23827.518742] netlink_sendmsg+0x743/0xc20<br /> [23827.519467] sock_sendmsg+0xb2/0xe0<br /> [23827.520131] ____sys_sendmsg+0x590/0x770<br /> [23827.520851] ___sys_sendmsg+0xd8/0x160<br /> [23827.521552] __sys_sendmsg+0xb7/0x140<br /> [23827.522238] do_syscall_64+0x3a/0x70<br /> [23827.522907] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [23827.523797]<br /> [23827.524163] Freed by task 25948:<br /> [23827.524780] kasan_save_stack+0x1b/0x40<br /> [23827.525488] kasan_set_track+0x1c/0x30<br /> [23827.526187] kasan_set_free_info+0x20/0x30<br /> [23827.526968] __kasan_slab_free+0xed/0x130<br /> [23827.527709] slab_free_freelist_hook+0xcf/0x1d0<br /> [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0<br /> [23827.529317] kfree_rcu_work+0x55f/0xb70<br /> [23827.530024] process_one_work+0x8ac/0x14e0<br /> [23827.530770] worker_thread+0x53b/0x1220<br /> [23827.531480] kthread+0x328/0x3f0<br /> [23827.532114] ret_from_fork+0x1f/0x30<br /> [23827.532785]<br /> [23827.533147] Last potentially related work creation:<br /> [23827.534007] kasan_save_stack+0x1b/0x40<br /> [23827.534710] kasan_record_aux_stack+0xab/0xc0<br /> [23827.535492] kvfree_call_rcu+0x31/0x7b0<br /> [23827.536206] mlx5e_tc_del<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/ioremap: Map EFI-reserved memory as encrypted for SEV<br /> <br /> Some drivers require memory that is marked as EFI boot services<br /> data. In order for this memory to not be re-used by the kernel<br /> after ExitBootServices(), efi_mem_reserve() is used to preserve it<br /> by inserting a new EFI memory descriptor and marking it with the<br /> EFI_MEMORY_RUNTIME attribute.<br /> <br /> Under SEV, memory marked with the EFI_MEMORY_RUNTIME attribute needs to<br /> be mapped encrypted by Linux, otherwise the kernel might crash at boot<br /> like below:<br /> <br /> EFI Variables Facility v0.08 2004-May-17<br /> general protection fault, probably for non-canonical address 0x3597688770a868b2: 0000 [#1] SMP NOPTI<br /> CPU: 13 PID: 1 Comm: swapper/0 Not tainted 5.12.4-2-default #1 openSUSE Tumbleweed<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:efi_mokvar_entry_next<br /> [...]<br /> Call Trace:<br /> efi_mokvar_sysfs_init<br /> ? efi_mokvar_table_init<br /> do_one_initcall<br /> ? __kmalloc<br /> kernel_init_freeable<br /> ? rest_init<br /> kernel_init<br /> ret_from_fork<br /> <br /> Expand the __ioremap_check_other() function to additionally check for<br /> this other type of boot data reserved at runtime and indicate that it<br /> should be mapped encrypted for an SEV guest.<br /> <br /> [ bp: Massage commit message. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: aardvark: Fix kernel panic during PIO transfer<br /> <br /> Trying to start a new PIO transfer by writing value 0 in PIO_START register<br /> when previous transfer has not yet completed (which is indicated by value 1<br /> in PIO_START) causes an External Abort on CPU, which results in kernel<br /> panic:<br /> <br /> SError Interrupt on CPU0, code 0xbf000002 -- SError<br /> Kernel panic - not syncing: Asynchronous SError Interrupt<br /> <br /> To prevent kernel panic, it is required to reject a new PIO transfer when<br /> previous one has not finished yet.<br /> <br /> If previous PIO transfer is not finished yet, the kernel may issue a new<br /> PIO request only if the previous PIO transfer timed out.<br /> <br /> In the past the root cause of this issue was incorrectly identified (as it<br /> often happens during link retraining or after link down event) and special<br /> hack was implemented in Trusted Firmware to catch all SError events in EL3,<br /> to ignore errors with code 0xbf000002 and not forwarding any other errors<br /> to kernel and instead throw panic from EL3 Trusted Firmware handler.<br /> <br /> Links to discussion and patches about this issue:<br /> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50<br /> https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/<br /> https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/<br /> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541<br /> <br /> But the real cause was the fact that during link retraining or after link<br /> down event the PIO transfer may take longer time, up to the 1.44s until it<br /> times out. This increased probability that a new PIO transfer would be<br /> issued by kernel while previous one has not finished yet.<br /> <br /> After applying this change into the kernel, it is possible to revert the<br /> mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.