vdanen/rhvex-cve huggingface dataset:
CVE-2024-35806 (Moderate severity, published 2024-05-16)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: A vulnerability was found in the Freescale QBMan driver in the Linux kernel. This issue stems from interrupts not being disabled when taking the cgr_lock, potentially causing race conditions or improper interrupt handling.
Statement: Red Hat Enterprise Linux is not vulnerable to this CVE, as it does not affect the versions or configurations of the Linux kernel used in its distributions.
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-2024-58065 (Moderate severity, published 2025-03-05)
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:

clk: mmp: pxa1908-apbc: Fix NULL vs IS_ERR() check

The devm_kzalloc() function returns NULL on error, not error pointers.
Fix the check.
CVE-2024-35943 (Moderate severity, published 2024-05-18)
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:

pmdomain: ti: Add a null pointer check to the omap_prm_domain_init

devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
CVE-2024-50140 (Moderate severity, published 2024-11-06)
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-413
Description: In the Linux kernel, the following vulnerability has been resolved:

sched/core: Disable page allocation in task_tick_mm_cid()

With KASAN and PREEMPT_RT enabled, calling task_work_add() in
task_tick_mm_cid() may cause the following splat.

[   63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
[   63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe
[   63.696416] preempt_count: 10001, expected: 0
[   63.696416] RCU nest depth: 1, expected: 1

This problem is caused by the following call trace.

  sched_tick() [ acquire rq->__lock ]
   -> task_tick_mm_cid()
    -> task_work_add()
     -> __kasan_record_aux_stack()
      -> kasan_save_stack()
       -> stack_depot_save_flags()
        -> alloc_pages_mpol_noprof()
         -> __alloc_pages_noprof()
	  -> get_page_from_freelist()
	   -> rmqueue()
	    -> rmqueue_pcplist()
	     -> __rmqueue_pcplist()
	      -> rmqueue_bulk()
	       -> rt_spin_lock()

The rq lock is a raw_spinlock_t. We can't sleep while holding
it. IOW, we can't call alloc_pages() in stack_depot_save_flags().

The task_tick_mm_cid() function with its task_work_add() call was
introduced by commit 223baf9d17f2 ("sched: Fix performance regression
introduced by mm_cid") in v6.4 kernel.

Fortunately, there is a kasan_record_aux_stack_noalloc() variant that
calls stack_depot_save_flags() while not allowing it to allocate
new pages.  To allow task_tick_mm_cid() to use task_work without
page allocation, a new TWAF_NO_ALLOC flag is added to enable calling
kasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack()
if set. The task_tick_mm_cid() function is modified to add this new flag.

The possible downside is the missing stack trace in a KASAN report due
to new page allocation required when task_work_add_noallloc() is called
which should be rare.
CVE-2024-23897 (Critical severity, published 2024-01-08)
CVSS score: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-88
Description: A flaw was found in Jenkins, which uses the args4j library to parse command arguments and options on the Jenkins controller when processing CLI commands. This command parser has a feature that replaces the "@" character followed by a file path in an argument with the file’s contents (expandAtFiles). This feature is enabled by default; Jenkins 2.441 and earlier as well as LTS 2.426.2 and earlier do not disable it.
Mitigation: Disabling access to the CLI is expected to prevent exploitation completely. Doing so is strongly recommended to administrators unable to immediately update to Jenkins 2.442, LTS 2.426.3 or LTS 2.440.1. Applying this workaround does not require a Jenkins restart.
CVE-2024-47685 (Moderate severity, published 2024-10-20)
CVSS score: 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N)
CWE: CWE-908
Description: A flaw was found in the Netfilter and IPV6 functionality in the Linux kernel leading to a leak of 4 random bits. This issue may allow a remote user to preform an unauthorized read of random bits from the server.
Statement: This issue is considered to be a moderate impact flaw, as the leaked data is a tcp stack and not the whole kernel. It does not seem to affect the availability. A remote user can potentially read 4 bits of random data from the server memory, but has no control of what is in the 4 bits and cannot bring any harm to the server from it.
Mitigation: If IPV6 or netfilter is not being used, then the issue is not applicable.

In order to trigger this issue, the local user needs to enable Netfilter and IPV6 (that requires the ability to create user/net namespaces).

On non-containerized deployments of Red Hat Enterprise Linux 8, you can disable user namespaces by setting user.max_user_namespaces to 0:

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf
# sysctl -p /etc/sysctl.d/userns.conf

On containerized deployments, such as Red Hat OpenShift Container Platform, do not use this mitigation as this functionality needs to be enabled.
CVE-2024-38388 (Low severity, published 2024-06-20)
CVSS score: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-99
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup

Use the control private_free callback to free the associated data
block. This ensures that the memory won't leak, whatever way the
control gets destroyed.

The original implementation didn't actually remove the ALSA
controls in hda_cs_dsp_control_remove(). It only freed the internal
tracking structure. This meant it was possible to remove/unload the
amp driver while leaving its ALSA controls still present in the
soundcard. Obviously attempting to access them could cause segfaults
or at least dereferencing stale pointers.
CVE-2024-10973 (Moderate severity, published 2024-11-06)
CVSS score: 5.7 (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
CWE: CWE-319
Description: A vulnerability was found in Keycloak. The environment option `KC_CACHE_EMBEDDED_MTLS_ENABLED` does not work and the JGroups replication configuration is always used in plain text which can allow an attacker that has access to adjacent networks related to JGroups to read sensitive information.
Statement: After evaluation of this vulnerability, Keycloak 22 and 24 are not affected. Red Hat currently only ships Red Hat Build of Keycloak 22 and 24.
CVE-2024-56610 (Low severity, published 2024-12-26)
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:

kcsan: Turn report_filterlist_lock into a raw_spinlock

Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see
splats like:

| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
| preempt_count: 10002, expected: 0
| RCU nest depth: 0, expected: 0
| no locks held by swapper/1/0.
| irq event stamp: 156674
| hardirqs last  enabled at (156673): [<ffffffff81130bd9>] do_idle+0x1f9/0x240
| hardirqs last disabled at (156674): [<ffffffff82254f84>] sysvec_apic_timer_interrupt+0x14/0xc0
| softirqs last  enabled at (0): [<ffffffff81099f47>] copy_process+0xfc7/0x4b60
| softirqs last disabled at (0): [<0000000000000000>] 0x0
| Preemption disabled at:
| [<ffffffff814a3e2a>] paint_ptr+0x2a/0x90
| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
| Call Trace:
|  <IRQ>
|  dump_stack_lvl+0x7e/0xc0
|  dump_stack+0x1d/0x30
|  __might_resched+0x1a2/0x270
|  rt_spin_lock+0x68/0x170
|  kcsan_skip_report_debugfs+0x43/0xe0
|  print_report+0xb5/0x590
|  kcsan_report_known_origin+0x1b1/0x1d0
|  kcsan_setup_watchpoint+0x348/0x650
|  __tsan_unaligned_write1+0x16d/0x1d0
|  hrtimer_interrupt+0x3d6/0x430
|  __sysvec_apic_timer_interrupt+0xe8/0x3a0
|  sysvec_apic_timer_interrupt+0x97/0xc0
|  </IRQ>

On a detected data race, KCSAN's reporting logic checks if it should
filter the report. That list is protected by the report_filterlist_lock
*non-raw* spinlock which may sleep on RT kernels.

Since KCSAN may report data races in any context, convert it to a
raw_spinlock.

This requires being careful about when to allocate memory for the filter
list itself which can be done via KCSAN's debugfs interface. Concurrent
modification of the filter list via debugfs should be rare: the chosen
strategy is to optimistically pre-allocate memory before the critical
section and discard if unused.
CVE-2024-57902 (Moderate severity, published 2025-01-14)
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-99
Description: In the Linux kernel, the following vulnerability has been resolved:

af_packet: fix vlan_get_tci() vs MSG_PEEK

Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found
by syzbot.

Rework vlan_get_tci() to not touch skb at all,
so that it can be used from many cpus on the same skb.

Add a const qualifier to skb argument.

[1]
skbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:<NULL>
------------[ cut here ]------------
 kernel BUG at net/core/skbuff.c:206 !
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]
 RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216
Code: 0b 8d 48 c7 c6 9e 6c 26 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 3a 5a 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
RSP: 0018:ffffc90003baf5b8 EFLAGS: 00010286
RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50
R10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140
R13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014
FS:  00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd65753000 CR3: 0000000031720000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
  skb_push+0xe5/0x100 net/core/skbuff.c:2636
  vlan_get_tci+0x272/0x550 net/packet/af_packet.c:565
  packet_recvmsg+0x13c9/0x1ef0 net/packet/af_packet.c:3616
  sock_recvmsg_nosec net/socket.c:1044 [inline]
  sock_recvmsg+0x22f/0x280 net/socket.c:1066
  ____sys_recvmsg+0x1c6/0x480 net/socket.c:2814
  ___sys_recvmsg net/socket.c:2856 [inline]
  do_recvmmsg+0x426/0xab0 net/socket.c:2951
  __sys_recvmmsg net/socket.c:3025 [inline]
  __do_sys_recvmmsg net/socket.c:3048 [inline]
  __se_sys_recvmmsg net/socket.c:3041 [inline]
  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3041
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
CVE-2024-26142 (Moderate severity, published 2024-02-23)
CVSS score: 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-400
Description: A flaw was found in actionpack rubygem during the parsing of the Accept header. This issue ma allow a malicious actor to craft a header which will lead the action dispatch component to take an unexpected amount of time, leading to a Denial of Service, impacting the application's availability.
CVE-2024-53042 (Moderate severity, published 2024-11-18)
CVSS score: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
CWE: CWE-662
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()

There are code paths from which the function is called without holding
the RCU read lock, resulting in a suspicious RCU usage warning [1].

Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire
the RCU read lock before calling
l3mdev_master_upper_ifindex_by_index_rcu().

[1]
WARNING: suspicious RCU usage
6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted
-----------------------------
net/core/dev.c:876 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ip/361:
 #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60

stack backtrace:
CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
 <TASK>
 dump_stack_lvl+0xba/0x110
 lockdep_rcu_suspicious.cold+0x4f/0xd6
 dev_get_by_index_rcu+0x1d3/0x210
 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0
 ip_tunnel_bind_dev+0x72f/0xa00
 ip_tunnel_newlink+0x368/0x7a0
 ipgre_newlink+0x14c/0x170
 __rtnl_newlink+0x1173/0x19c0
 rtnl_newlink+0x6c/0xa0
 rtnetlink_rcv_msg+0x3cc/0xf60
 netlink_rcv_skb+0x171/0x450
 netlink_unicast+0x539/0x7f0
 netlink_sendmsg+0x8c1/0xd80
 ____sys_sendmsg+0x8f9/0xc20
 ___sys_sendmsg+0x197/0x1e0
 __sys_sendmsg+0x122/0x1f0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2024-7260 (Moderate severity, published 2024-09-09)
CVSS score: 6.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)
CWE: CWE-601
Description: An open redirect vulnerability was found in Keycloak. A specially crafted URL can be constructed where the referrer and referrer_uri parameters are made to trick a user to visit a malicious webpage. A trusted URL can trick users and automation into believing that the URL is safe, when, in fact, it redirects to a malicious server. This issue can result in a victim inadvertently trusting the destination of the redirect, potentially leading to a successful phishing attack or other types of attacks.

Once a crafted URL is made, it can be sent to a Keycloak admin via email for example. This will trigger this vulnerability when the user visits the page and clicks the link. A malicious actor can use this to target users they know are Keycloak admins for further attacks. It may also be possible to bypass other domain-related security checks, such as supplying this as a OAuth redirect uri. The malicious actor can further obfuscate the redirect_uri using URL encoding, to hide the text of the actual malicious website domain.
Statement: Red Hat has evaluated this vulnerability and it only affects the Red Hat Build of Keycloak (RHBK).

Within regulated environments, a combination of the following controls acts as a significant barrier to successfully exploiting a CWE-601: URL Redirection to Untrusted Site ('Open Redirect') vulnerability and therefore downgrades the severity of this particular CVE from Moderate to Low.

The platform limits access to external systems and enforces strict network security boundaries through a deny-all, allow-exception system implementation. This ensures that access to external websites and systems is strictly controlled, monitored, and, if necessary, restricted. By enforcing policies on which external sites or domains users and applications can interact with, this control minimizes the risk of users being redirected to malicious websites. For example, organizations may implement allowlists of approved URLs or domains, blocking any redirections to untrusted or unauthorized sites. The platform's implementation of boundary protection includes firewalls, gateways, and intrusion detection/prevention systems. This control prevents unauthorized traffic, including malicious redirect requests, from entering or leaving the internal network. The boundary protection control can enforce URL filtering, domain allowlisting, and content inspection to block redirection attempts to known malicious domains. When configured properly, boundary protection mechanisms ensure that even if an open redirect vulnerability is exploited, the impact is limited by blocking access to harmful external sites.
CVE-2024-26841 (Moderate severity, published 2024-04-16)
CVSS score: 0 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:N)
Description: A flaw was found in the Linux kernel. This vulnerability specifically affects LoongArch processors. The issue is related to the CPU sibling map, which is not correctly updated when non-boot CPUs are disabled. This issue could lead to errors on Symmetric Multi-Threading (SMT) systems, such as generating warnings like "jump label: negative count!" when disabling certain CPUs.
The vulnerability could potentially cause system instability or kernel crashes, especially in environments that rely on SMT. The issue was resolved by defining and calling the function clear_cpu_sibling_map() to properly manage the CPU sibling map, preventing the errors. While this vulnerability doesn't appear to be remotely exploitable, it could still impact local users under specific conditions​.
CVE-2024-41090 (Important severity, published 2024-07-24)
CVSS score: 7.1 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H)
CWE: CWE-20
Description: A denial of service (DoS) attack was found in the mlx5 driver in the Linux kernel. A KVM guest VM using virtio-net can crash the host by sending a short packet, for example, size < ETH_HLEN. The packet may traverse through vhost-net, macvtap, and vlan without any validation or drop. When this packet is presented to the mlx5 driver on the host side, the kernel panic happens since mlx5_core assumes the frame size is always >= ETH_HLEN.
CVE-2024-33655 (Low severity, published 2024-05-08)
CVSS score: 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)
CWE: CWE-400
Description: A DNSBomb flaw was found in the unbound package. The DNSBomb attack works by sending low-rate spoofed queries for a malicious zone to Unbound. By controlling the delay of the malicious authoritative answers, Unbound slowly accumulates pending answers for the spoofed addresses. When the authoritative answers become available to Unbound at the same time, Unbound starts serving all the accumulated queries. This results in large-sized, concentrated response bursts to the spoofed addresses.
CVE-2024-36007 (Low severity, published 2024-05-19)
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:

mlxsw: spectrum_acl_tcam: Fix warning during rehash

As previously explained, the rehash delayed work migrates filters from
one region to another. This is done by iterating over all chunks (all
the filters with the same priority) in the region and in each chunk
iterating over all the filters.

When the work runs out of credits it stores the current chunk and entry
as markers in the per-work context so that it would know where to resume
the migration from the next time the work is scheduled.

Upon error, the chunk marker is reset to NULL, but without resetting the
entry markers despite being relative to it. This can result in migration
being resumed from an entry that does not belong to the chunk being
migrated. In turn, this will eventually lead to a chunk being iterated
over as if it is an entry. Because of how the two structures happen to
be defined, this does not lead to KASAN splats, but to warnings such as
[1].

Fix by creating a helper that resets all the markers and call it from
all the places the currently only reset the chunk marker. For good
measures also call it when starting a completely new rehash. Add a
warning to avoid future cases.

[1]
WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0
Modules linked in:
CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G        W          6.9.0-rc3-custom-00880-g29e61d91b77b #29
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_afk_encode+0x242/0x2f0
[...]
Call Trace:
 <TASK>
 mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0
 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470
 process_one_work+0x151/0x370
 worker_thread+0x2cb/0x3e0
 kthread+0xd0/0x100
 ret_from_fork+0x34/0x50
 </TASK>
CVE-2024-26904 (Moderate severity, published 2024-04-16)
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-362
Description: A data race vulnerability in the `btrfs_use_block_rsv()` function in the Linux kernel's btrfs filesystem code has been resolved. This issue led to inconsistent block reserve management, potentially causing data corruption or other filesystem errors.
Statement: Red Hat Enterprise Linux is not vulnerable to this CVE, as it does not affect the versions or configurations of the Linux kernel used in its distributions.
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-2024-56755 (Moderate severity, published 2024-12-28)
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-401
Description: In the Linux kernel, the following vulnerability has been resolved:

netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING

In fscache_create_volume(), there is a missing memory barrier between the
bit-clearing operation and the wake-up operation. This may cause a
situation where, after a wake-up, the bit-clearing operation hasn't been
detected yet, leading to an indefinite wait. The triggering process is as
follows:

  [cookie1]                [cookie2]                  [volume_work]
fscache_perform_lookup
  fscache_create_volume
                        fscache_perform_lookup
                          fscache_create_volume
			                        fscache_create_volume_work
                                                  cachefiles_acquire_volume
                                                  clear_and_wake_up_bit
    test_and_set_bit
                            test_and_set_bit
                              goto maybe_wait
      goto no_wait

In the above process, cookie1 and cookie2 has the same volume. When cookie1
enters the -no_wait- process, it will clear the bit and wake up the waiting
process. If a barrier is missing, it may cause cookie2 to remain in the
-wait- process indefinitely.

In commit 3288666c7256 ("fscache: Use clear_and_wake_up_bit() in
fscache_create_volume_work()"), barriers were added to similar operations
in fscache_create_volume_work(), but fscache_create_volume() was missed.

By combining the clear and wake operations into clear_and_wake_up_bit() to
fix this issue.
CVE-2024-49859 (Moderate severity, published 2024-10-20)
CVSS score: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-362
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to check atomic_file in f2fs ioctl interfaces

Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(),
f2fs_move_file_range(), and f2fs_defragment_range() missed to
check atomic_write status, which may cause potential race issue,
fix it.