vdanen/rhvex-cve huggingface dataset:
CVE-2025-38011 (Low severity, published 2025-06-17)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: csa unmap use uninterruptible lock

After process exit to unmap csa and free GPU vm, if signal is accepted
and then waiting to take vm lock is interrupted and return, it causes
memory leaking and below warning backtrace.

Change to use uninterruptible wait lock fix the issue.

WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525
 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu]
 Call Trace:
  <TASK>
  drm_file_free.part.0+0x1da/0x230 [drm]
  drm_close_helper.isra.0+0x65/0x70 [drm]
  drm_release+0x6a/0x120 [drm]
  amdgpu_drm_release+0x51/0x60 [amdgpu]
  __fput+0x9f/0x280
  ____fput+0xe/0x20
  task_work_run+0x67/0xa0
  do_exit+0x217/0x3c0
  do_group_exit+0x3b/0xb0
  get_signal+0x14a/0x8d0
  arch_do_signal_or_restart+0xde/0x100
  exit_to_user_mode_loop+0xc1/0x1a0
  exit_to_user_mode_prepare+0xf4/0x100
  syscall_exit_to_user_mode+0x17/0x40
  do_syscall_64+0x69/0xc0

(cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)
CVE-2025-24032 (Moderate severity, published 2025-02-10)
CVSS score: 8 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L)
CWE: CWE-287
Description: A flaw was found in the pam_pkcs11 Linux-PAM login module. If the `cert_policy` is set to none, which is the default value, then pam_pkcs11 will only check if the user is capable of logging into the token. This flaw allows an attacker to create a different token with the user's public data, for example, the user's certificate and a PIN known to the attacker. If no signature with the private key is required, the attacker can log in as a user with that created token.
Statement: This vulnerability is of moderate severity because it only applies when the configuration explicitly disables signature verification (cert_policy = none), which is not a secure best practice. The attack requires an adversary to create a fake token using the victim’s public certificate and a known PIN, but it does not compromise the private key itself. Since private key possession is typically required for strong authentication, systems enforcing proper certificate verification (including signature validation) remain unaffected. Additionally, RHEL is not vulnerable by default, further reducing the real-world impact.
Mitigation: Restrict the cert_policy value to `signature` in the pam_pkcs11.conf configuration file (`cert_policy = signature`).
CVE-2025-21725 (Moderate severity, published 2025-02-26)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-369
Description: A vulnerability was found in the Linux kernel's Server Message Block (SMB) client implementation, specifically within the Common Internet File System (CIFS) module. The issue arises when the client attempts to process network interface information provided by the server, particularly the LinkSpeed parameter. If the server omits this parameter or provides an unexpected value, the client may attempt to perform a division operation with a zero value, leading to a divide-by-zero error and subsequent kernel crash. This misconfiguration on the server could lead to system failure.
CVE-2025-38154 (Moderate severity, published 2025-07-02)
CVSS score: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Avoid using sk_socket after free when sending

The sk->sk_socket is not locked or referenced in backlog thread, and
during the call to skb_send_sock(), there is a race condition with
the release of sk_socket. All types of sockets(tcp/udp/unix/vsock)
will be affected.

Race conditions:
'''
CPU0                               CPU1

backlog::skb_send_sock
  sendmsg_unlocked
    sock_sendmsg
      sock_sendmsg_nosec
                                   close(fd):
                                     ...
                                     ops->release() -> sock_map_close()
                                     sk_socket->ops = NULL
                                     free(socket)
      sock->ops->sendmsg
            ^
            panic here
'''

The ref of psock become 0 after sock_map_close() executed.
'''
void sock_map_close()
{
    ...
    if (likely(psock)) {
    ...
    // !! here we remove psock and the ref of psock become 0
    sock_map_remove_links(sk, psock)
    psock = sk_psock_get(sk);
    if (unlikely(!psock))
        goto no_psock; <=== Control jumps here via goto
        ...
        cancel_delayed_work_sync(&psock->work); <=== not executed
        sk_psock_put(sk, psock);
        ...
}
'''

Based on the fact that we already wait for the workqueue to finish in
sock_map_close() if psock is held, we simply increase the psock
reference count to avoid race conditions.

With this patch, if the backlog thread is running, sock_map_close() will
wait for the backlog thread to complete and cancel all pending work.

If no backlog running, any pending work that hasn't started by then will
fail when invoked by sk_psock_get(), as the psock reference count have
been zeroed, and sk_psock_drop() will cancel all jobs via
cancel_delayed_work_sync().

In summary, we require synchronization to coordinate the backlog thread
and close() thread.

The panic I catched:
'''
Workqueue: events sk_psock_backlog
RIP: 0010:sock_sendmsg+0x21d/0x440
RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001
...
Call Trace:
 <TASK>
 ? die_addr+0x40/0xa0
 ? exc_general_protection+0x14c/0x230
 ? asm_exc_general_protection+0x26/0x30
 ? sock_sendmsg+0x21d/0x440
 ? sock_sendmsg+0x3e0/0x440
 ? __pfx_sock_sendmsg+0x10/0x10
 __skb_send_sock+0x543/0xb70
 sk_psock_backlog+0x247/0xb80
...
'''
CVE-2025-37921 (Moderate severity, published 2025-05-19)
CVSS score: 4.1 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

vxlan: vnifilter: Fix unlocked deletion of default FDB entry

When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB
entry associated with the default remote (assuming one was configured)
is deleted without holding the hash lock. This is wrong and will result
in a warning [1] being generated by the lockdep annotation that was
added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").

Reproducer:

 # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1
 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0
 # bridge vni del vni 10010 dev vx0

Fix by acquiring the hash lock before the deletion and releasing it
afterwards. Blame the original commit that introduced the issue rather
than the one that exposed it.

[1]
WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
[...]
RIP: 0010:vxlan_find_mac+0x17f/0x1a0
[...]
Call Trace:
 <TASK>
 __vxlan_fdb_delete+0xbe/0x560
 vxlan_vni_delete_group+0x2ba/0x940
 vxlan_vni_del.isra.0+0x15f/0x580
 vxlan_process_vni_filter+0x38b/0x7b0
 vxlan_vnifilter_process+0x3bb/0x510
 rtnetlink_rcv_msg+0x2f7/0xb70
 netlink_rcv_skb+0x131/0x360
 netlink_unicast+0x426/0x710
 netlink_sendmsg+0x75a/0xc20
 __sock_sendmsg+0xc1/0x150
 ____sys_sendmsg+0x5aa/0x7b0
 ___sys_sendmsg+0xfc/0x180
 __sys_sendmsg+0x121/0x1b0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Statement: VXLAN vnifilter bug causing unprotected FDB deletion. Triggers kernel WARN and may lead to instability. No exploitability or privilege escalation, but relevant for robustness in advanced VXLAN setups.
CVE-2025-1219 (Moderate severity, published 2025-03-30)
CVSS score: 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N)
CWE: CWE-20
Description: A flaw was found in PHP's DOM and SimpleXML extensions. This vulnerability allows incorrect parsing of a redirected HTTP resource via improper content-type header handling.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2025-37864 (Moderate severity, published 2025-05-08)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: clean up FDB, MDB, VLAN entries on unbind

As explained in many places such as commit b117e1e8a86d ("net: dsa:
delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given
the assumption that higher layers have balanced additions/deletions.
As such, it only makes sense to be extremely vocal when those
assumptions are violated and the driver unbinds with entries still
present.

But Ido Schimmel points out a very simple situation where that is wrong:
https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/
(also briefly discussed by me in the aforementioned commit).

Basically, while the bridge bypass operations are not something that DSA
explicitly documents, and for the majority of DSA drivers this API
simply causes them to go to promiscuous mode, that isn't the case for
all drivers. Some have the necessary requirements for bridge bypass
operations to do something useful - see dsa_switch_supports_uc_filtering().

Although in tools/testing/selftests/net/forwarding/local_termination.sh,
we made an effort to popularize better mechanisms to manage address
filters on DSA interfaces from user space - namely macvlan for unicast,
and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the
fact is that 'bridge fdb add ... self static local' also exists as
kernel UAPI, and might be useful to someone, even if only for a quick
hack.

It seems counter-productive to block that path by implementing shim
.ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP
in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from
running, although we could do that.

Accepting that cleanup is necessary seems to be the only option.
Especially since we appear to be coming back at this from a different
angle as well. Russell King is noticing that the WARN_ON() triggers even
for VLANs:
https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/

What happens in the bug report above is that dsa_port_do_vlan_del() fails,
then the VLAN entry lingers on, and then we warn on unbind and leak it.

This is not a straight revert of the blamed commit, but we now add an
informational print to the kernel log (to still have a way to see
that bugs exist), and some extra comments gathered from past years'
experience, to justify the logic.
CVE-2025-38338 (Moderate severity, published 2025-07-09)
CVSS score: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()

Sometimes, when a file was read while it was being truncated by
another NFS client, the kernel could deadlock because folio_unlock()
was called twice, and the second call would XOR back the `PG_locked`
flag.

Most of the time (depending on the timing of the truncation), nobody
notices the problem because folio_unlock() gets called three times,
which flips `PG_locked` back off:

 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,
    nfs_return_empty_folio
 2. vfs_read, nfs_read_folio, ... netfs_read_collection,
    netfs_unlock_abandoned_read_pages
 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,
    nfs_return_empty_folio

The problem is that nfs_read_add_folio() is not supposed to unlock the
folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is
missing in nfs_return_empty_folio().

Rarely this leads to a warning in netfs_read_collection():

 ------------[ cut here ]------------
 R=0000031c: folio 10 is not locked
 WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00
 [...]
 Workqueue: events_unbound netfs_read_collection_worker
 RIP: 0010:netfs_read_collection+0x7c0/0xf00
 [...]
 Call Trace:
  <TASK>
  netfs_read_collection_worker+0x67/0x80
  process_one_work+0x12e/0x2c0
  worker_thread+0x295/0x3a0

Most of the time, however, processes just get stuck forever in
folio_wait_bit_common(), waiting for `PG_locked` to disappear, which
never happens because nobody is really holding the folio lock.
CVE-2025-32365 (Moderate severity, published 2025-04-04)
CVSS score: 4 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)
CWE: CWE-125
Description: A flaw was found in Poppler. This vulnerability allows out-of-bounds reads via crafted input files that trigger the JBIG2Bitmap::combine function due to a misplaced isOk check.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2025-38292 (Moderate severity, published 2025-07-09)
CVSS score: 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H)
CWE: CWE-416
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix invalid access to memory

In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean
is_continuation is part of rxcb.
Currently, after freeing the skb, the rxcb->is_continuation accessed
again which is wrong since the memory is already freed.
This might lead use-after-free error.

Hence, fix by locally defining bool is_continuation from rxcb,
so that after freeing skb, is_continuation can be used.

Compile tested only.
Statement: This patch addresses a use-after-free vulnerability in the ath12k_dp_rx_msdu_coalesce() function, where memory was accessed after freeing the associated skb. Specifically, the rxcb->is_continuation field was read post-free, leading to potential kernel crashes. The patch stores the value before freeing the buffer. The Required Privileges for CVSS is Low (PR:L), because triggering this flaw likely requires the ability to inject or manipulate network traffic handled by the Wi-Fi driver, which is feasible from a local user space process using standard socket interfaces or crafted packets.
Mitigation: To mitigate this issue, prevent module ath12k from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
CVE-2025-38046 (Moderate severity, published 2025-06-17)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: No description is available for this CVE.
CVE-2025-21637 (Low severity, published 2025-01-18)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: udp_port: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using
container_of().

Note that table->data could also be used directly, but that would
increase the size of this fix, while 'sctp.ctl_sock' still needs to be
retrieved from 'net' structure.
CVE-2025-38416 (Moderate severity, published 2025-07-24)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: No description is available for this CVE.
CVE-2025-27219 (Moderate severity, published 2025-03-02)
CVSS score: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)
CWE: CWE-770
Description: A flaw was found in Ruby's CGI gem. Processing specially crafted large cookies with the CGI::Cookie.parse method can cause excessive resource consumption due to a missing limit on the length of the raw cookie value, resulting in a denial of service.
Statement: This issue will cause an excessive resource consumption, potentially resulting in a bad application performance. However, an attacker does have the ability to completely deny service to legitimate users. For this reason, this vulnerability has been rated with a moderate severity.

Within regulated environments, a combination of the following controls acts as a significant barrier to successfully exploiting a CWE-770: Allocation of Resources Without Limits or Throttling vulnerability and therefore downgrades the severity of this particular CVE from Moderate to Low.

The platform enforces hardening guidelines to apply the most restrictive settings required for operations, while baseline configurations maintain secure system and software states. A defense-in-depth monitoring strategy includes perimeter firewalls and endpoint protection services that detect excessive resource usage caused by malicious activity or system misconfigurations. In the event of exploitation, process isolation ensures workloads operate in separate environments, preventing any single process from overconsuming CPU or memory and degrading system performance.
Mitigation: Do not process large cookies or strings with the CGI::Cookie.parse method from the CGI library. Adding a check to verify and limit the length of the cookie or string before processing it will mitigate this vulnerability.
CVE-2025-38103 (Moderate severity, published 2025-07-02)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()

Update struct hid_descriptor to better reflect the mandatory and
optional parts of the HID Descriptor as per USB HID 1.11 specification.
Note: the kernel currently does not parse any optional HID class
descriptors, only the mandatory report descriptor.

Update all references to member element desc[0] to rpt_desc.

Add test to verify bLength and bNumDescriptors values are valid.

Replace the for loop with direct access to the mandatory HID class
descriptor member for the report descriptor. This eliminates the
possibility of getting an out-of-bounds fault.

Add a warning message if the HID descriptor contains any unsupported
optional HID class descriptors.
CVE-2025-0633 (Moderate severity, published 2025-02-19)
CVSS score: 4 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)
CWE: CWE-122
Description: A flaw was found in iniparser. This vulnerability allows an attacker to read out-of-bound memory via iniparser_dumpsection_ini().
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
CVE-2025-30163 (Low severity, published 2025-03-24)
CVSS score: 3.4 (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N)
CWE: CWE-863
Description: Cilium is a networking, observability, and security solution with an eBPF-based dataplane. Node based network policies (`fromNodes` and `toNodes`) will incorrectly permit traffic to/from non-node endpoints that share the labels specified in `fromNodes` and `toNodes` sections of network policies. Node based network policy is disabled by default in Cilium. This issue affects: Cilium v1.16 between v1.16.0 and v1.16.7 inclusive and v1.17 between v1.17.0 and v1.17.1 inclusive. This issue is fixed in Cilium v1.16.8 and v1.17.2. Users can work around this issue by ensuring that the labels used in `fromNodes` and `toNodes` fields are used exclusively by nodes and not by other endpoints.
Statement: Node based network policy is disabled by default in Cilium.
Mitigation: Users can work around this issue by ensuring that the labels used in `fromNodes` and `toNodes` fields are used exclusively by nodes and not by other endpoints.
CVE-2025-21772 (Moderate severity, published 2025-02-26)
CVSS score: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
CWE: CWE-125
Description: In the Linux kernel, the following vulnerability has been resolved:

partitions: mac: fix handling of bogus partition table

Fix several issues in partition probing:

 - The bailout for a bad partoffset must use put_dev_sector(), since the
   preceding read_part_sector() succeeded.
 - If the partition table claims a silly sector size like 0xfff bytes
   (which results in partition table entries straddling sector boundaries),
   bail out instead of accessing out-of-bounds memory.
 - We must not assume that the partition table contains proper NUL
   termination - use strnlen() and strncmp() instead of strlen() and
   strcmp().
CVE-2025-37976 (Moderate severity, published 2025-05-19)
CVSS score: 5.1 (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
Description: No description is available for this CVE.
Statement: Incorrect use of source-ring fetch function for a destination ring led to invalid pointer access. The patch replaces the call with the correct API to prevent kernel crashes or memory corruption when processing destination ring entries.
CVE-2025-21908 (Moderate severity, published 2025-03-31)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-667
Description: In the Linux kernel, the following vulnerability has been resolved:

NFS: fix nfs_release_folio() to not deadlock via kcompactd writeback

Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so
nfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.

Otherwise NFS can deadlock waiting for kcompactd enduced writeback which
recurses back to NFS (which triggers writeback to NFSD via NFS loopback
mount on the same host, NFSD blocks waiting for XFS's call to
__filemap_get_folio):

6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.

{---
[58] "kcompactd0"
[<0>] folio_wait_bit+0xe8/0x200
[<0>] folio_wait_writeback+0x2b/0x80
[<0>] nfs_wb_folio+0x80/0x1b0 [nfs]
[<0>] nfs_release_folio+0x68/0x130 [nfs]
[<0>] split_huge_page_to_list_to_order+0x362/0x840
[<0>] migrate_pages_batch+0x43d/0xb90
[<0>] migrate_pages_sync+0x9a/0x240
[<0>] migrate_pages+0x93c/0x9f0
[<0>] compact_zone+0x8e2/0x1030
[<0>] compact_node+0xdb/0x120
[<0>] kcompactd+0x121/0x2e0
[<0>] kthread+0xcf/0x100
[<0>] ret_from_fork+0x31/0x40
[<0>] ret_from_fork_asm+0x1a/0x30
---}

[akpm@linux-foundation.org: fix build]
CVE-2025-38380 (Moderate severity, published 2025-07-24)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: No description is available for this CVE.
CVE-2025-24209 (Important severity, published 2025-04-06)
CVSS score: 8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
CWE: CWE-120
Description: A flaw was found in WebKitGTK. Processing malicious web content can cause a buffer overflow due to improper memory handling and result in an unexpected process crash.
Statement: To exploit this flaw, an attacker needs to trick a user into processing or loading malicious web content.
Mitigation: Do not process or load untrusted web content with WebKitGTK.

In Red Hat Enterprise Linux 7, the following packages require WebKitGTK4: evolution-data-server, glade, gnome-boxes, gnome-initial-setup, gnome-online-accounts, gnome-shell, shotwell, sushi and yelp.

This vulnerability can only be exploited when these packages are installed in the system and being used via a graphical interface to process untrusted web content, via GNOME for example. In gnome-shell, the vulnerability can be exploited by an attacker from the local network without user interaction.

To mitigate this vulnerability, consider removing these packages. Note that some of these packages are required by GNOME, removing them will also remove GNOME and other packages, breaking functionality. However, the server can still be used via the terminal interface.

Additionally, WebKitGTK3 is not required by any package. Therefore, it can be removed without consequences or break of functionality.