I got the same trouble in 10.5, one node in cluster Crashed (he was a slave), reboot without Galera, and I got it when i tried to reboot in cluster (without be a slave)

version affected 10.5.9

I have submitted a similar error: https://jira.mariadb.org/browse/MDEV-25605

Instead of "[ERROR] WSREP: std::bad_alloc", my cluster nodes are reporting "[ERROR] WSREP: deque::_M_new_elements_at_back"

Have the same issue here, with MariaDB 10.5.9.
[mysqld]
event_scheduler=1
log-error=/var/log/mariadb/mariadb.log
log_slave_updates=1
relay-log-purge=1

[mariadb-10.5]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
innodb_locks_unsafe_for_binlog=1
wsrep_on=ON
query_cache_size=0
query_cache_type=0
datadir=/var/lib/mysql
innodb_log_file_size=200M
innodb_file_per_table
innodb_flush_log_at_trx_commit=2
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so
wsrep_cluster_address="gcomm://"
wsrep_cluster_name='dev_galera_cluster'
wsrep_node_address='192.168.41.82'
wsrep_node_name='devnode1'
wsrep_sst_method=rsync
wsrep_sst_auth=db_user:admin
server_id=11
wsrep-restart-slave=1

Though I had wsrep_on=ON, there is only 1 node running (all other nodes are off line). This setup used to work until yesterday 14:30 GMT

Yesterday's logs:
2021-05-27 14:35:43 0 [Note] WSREP: Recovering GCache ring buffer: version: 2, UUID: b59c71a8-8bcd-11eb-850a-7fe030c3c134, offset: -1
2021-05-27 14:35:43 0 [Note] WSREP: GCache::RingBuffer initial scan... 0.0% ( 0/134217752 bytes) complete.
2021-05-27 14:35:43 0 [ERROR] WSREP: deque::_M_new_elements_at_back
2021-05-27 14:35:43 0 [ERROR] WSREP: Failed to create a new provider '/usr/lib64/galera-4/libgalera_smm.so' with options '': Failed to initialize wsrep
provider
2021-05-27 14:35:43 0 [ERROR] WSREP: Failed to load provider
2021-05-27 14:35:43 0 [ERROR] Aborting

I also noticed thousands of relay log files, since 1st May, with just about 600bytes sizes. The only way I had to solve the issue (mariadb not starting) was to set
wsrep_on=OFF
and then start the service. After connecting to CLI, I run :
reset slave;
and the relay logs are now cleared.

Today I made a new test, by setting wsrep to ON again. This is the result after a restart of mariadb service:

Today's log shows these errors:
2021-05-28 8:17:28 0 [Note] WSREP: Recovering GCache ring buffer: version: 2, UUID: b59c71a8-8bcd-11eb-850a-7fe030c3c134, offset: -1
2021-05-28 8:17:28 0 [Note] WSREP: GCache::RingBuffer initial scan... 0.0% ( 0/134217752 bytes) complete.
2021-05-28 8:17:28 0 [ERROR]* WSREP: deque::_M_new_elements_at_back*
2021-05-28 8:17:28 0 [ERROR] WSREP: Failed to create a new provider '/usr/lib64/galera-4/libgalera_smm.so' with options '': Failed to initialize wsrep provider
2021-05-28 8:17:28 0 [ERROR] WSREP: Failed to load provider
2021-05-28 8:17:28 0 [ERROR] Aborting

had to set wsrep=OFF once again to make it start.

Note: MariaDB was working fine since a few weeks, as a standalone node with the wsrep=ON option.
Back in early April, there was indeed 3 node with Galera cluster, but we had to turn off 2 of the nodes, leaving only 1.
There is no apparent reason for this node to not start...

Gcache ring buffer is not synced to disk and is not guaranteed to be consistent on restart. Hence some bogus numbers can be read from disk and care must be taken of potential exceptions. In particular here insert may throw exception for bogus seqno value. Fixed in commit 4bb58377cf3ee02e4c69ce329c2e099b07c79368