deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-2205
Published: 2025-03-12
Description: The GDPR Cookie Compliance – Cookie Banner, Cookie Consent, Cookie Notice – CCPA, DSGVO, RGPD plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 4.15.6 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.
CVSS Score: 4.4 (MEDIUM)
CWE: CWE-79
References: https://research.cleantalk.org/cve-2025-1622/; https://wpscan.com/vulnerability/7a903d61-2792-4fe0-a26b-f400f4a3124b/; https://www.wordfence.com/threat-intel/vulnerabilities/id/37da32e4-48a1-4830-a47c-c454d60c9811?source=cve
CVE: CVE-2025-24912
Published: 2025-03-12
Description: hostapd fails to process crafted RADIUS packets properly. When hostapd authenticates wi-fi devices with RADIUS authentication, an attacker in the position between the hostapd and the RADIUS server may inject crafted RADIUS packets and force RADIUS authentications to fail.
CVSS Score: 3.7 (LOW)
CWE: CWE-826
References: https://jvn.jp/en/jp/JVN19358384/; https://w1.fi/cgit/hostap/commit/?id=339a334551ca911187cc870f4f97ef08e11db109; https://w1.fi/cgit/hostap/commit/?id=726432d7622cc0088ac353d073b59628b590ea44
CVE: CVE-2024-13498
Published: 2025-03-12
Description: The NEX-Forms – Ultimate Form Builder – Contact forms and much more plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 8.8.1 via file uploads due to insufficient directory listing prevention and lack of randomization of file names. This makes it possible for unauthenticated attackers to extract sensitive data including files uploaded via a form.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-200
References: https://plugins.trac.wordpress.org/changeset/3235420/nex-forms-express-wp-form-builder; https://www.wordfence.com/threat-intel/vulnerabilities/id/f188a5e6-699e-4e1a-b4e4-7fb4056b0bee?source=cve
CVE: CVE-2024-12589
Published: 2025-03-12
Description: The Finale Lite – Sales Countdown Timer & Discount for WooCommerce plugin for WordPress is vulnerable to Stored DOM-Based Cross-Site Scripting via the countdown timer in all versions up to, and including, 2.19.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
CVSS Score: 6.4 (MEDIUM)
CWE: CWE-79, CWE-79
References: https://plugins.trac.wordpress.org/changeset/3247611/finale-woocommerce-sales-countdown-timer-discount; https://www.wordfence.com/threat-intel/vulnerabilities/id/ae0a001b-0792-4a32-8f49-5d4b1550f4be?source=cve
CVE: CVE-2024-13838
Published: 2025-03-12
Description: The Uncanny Automator – Easy Automation, Integration, Webhooks & Workflow Builder Plugin plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 6.2 via the 'call_webhook' method of the Automator_Send_Webhook class This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-918, CWE-918
References: https://plugins.trac.wordpress.org/changeset/3249921/uncanny-automator/trunk/src/core/lib/webhooks/class-automator-send-webhook.php; https://www.wordfence.com/threat-intel/vulnerabilities/id/29eeac86-6b33-49e6-a7e1-c80dee383d6f?source=cve
CVE: CVE-2024-58087
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix racy issue from session lookup and expire

Increment the session reference count within the lock for lookup to avoid
racy issue with session expire.
CVSS Score: 8.1 (HIGH)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/2107ab40629aeabbec369cf34b8cf0f288c3eb1b; https://git.kernel.org/stable/c/37a0e2b362b3150317fb6e2139de67b1e29ae5ff; https://git.kernel.org/stable/c/450a844c045ff0895d41b05a1cbe8febd1acfcfd
CVE: CVE-2024-13430
Published: 2025-03-12
Description: The Page Builder: Pagelayer – Drag and Drop website builder plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.9.8 via the 'pagelayer_builder_posts_shortcode' function due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from private posts that they should not have access to.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-284
References: https://plugins.trac.wordpress.org/changeset/3252081/pagelayer; https://www.wordfence.com/threat-intel/vulnerabilities/id/1de8da4c-dee7-4d59-a475-a969008aa0d4?source=cve
CVE: CVE-2024-13446
Published: 2025-03-12
Description: The Workreap plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 3.2.5. This is due to the plugin not properly validating a user's identity prior to (1) performing a social auto-login or (2) updating their profile details (e.g. password). This makes it possible for unauthenticated attackers to (1) login as an arbitrary user if their email address is known or (2) change an arbitrary user's password, including administrators, and leverage that to gain access to their account. NOTE: This vulnerability was partially fixed in version 3.2.5.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-288
References: https://themeforest.net/item/workreap-freelance-marketplace-wordpress-theme/23712454; https://www.wordfence.com/threat-intel/vulnerabilities/id/78c1308b-0849-4235-b2d6-0b1750a5614f?source=cve
CVE: CVE-2024-58088
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix deadlock when freeing cgroup storage

The following commit
bc235cdb423a ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]")
first introduced deadlock prevention for fentry/fexit programs attaching
on bpf_task_storage helpers. That commit also employed the logic in map
free path in its v6 version.

Later bpf_cgrp_storage was first introduced in
c4bcfb38a95e ("bpf: Implement cgroup storage available to non-cgroup-attached bpf progs")
which faces the same issue as bpf_task_storage, instead of its busy
counter, NULL was passed to bpf_local_storage_map_free() which opened
a window to cause deadlock:

	<TASK>
		(acquiring local_storage->lock)
	_raw_spin_lock_irqsave+0x3d/0x50
	bpf_local_storage_update+0xd1/0x460
	bpf_cgrp_storage_get+0x109/0x130
	bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170
	? __bpf_prog_enter_recur+0x16/0x80
	bpf_trampoline_[PII_REDACTED]+0x43/0xa4
	cgroup_storage_ptr+0x9/0x20
		(holding local_storage->lock)
	bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160
	bpf_selem_unlink_storage+0x6f/0x110
	bpf_local_storage_map_free+0xa2/0x110
	bpf_map_free_deferred+0x5b/0x90
	process_one_work+0x17c/0x390
	worker_thread+0x251/0x360
	kthread+0xd2/0x100
	ret_from_fork+0x34/0x50
	ret_from_fork_asm+0x1a/0x30
	</TASK>

Progs:
 - A: SEC("fentry/cgroup_storage_ptr")
   - cgid (BPF_MAP_TYPE_HASH)
	Record the id of the cgroup the current task belonging
	to in this hash map, using the address of the cgroup
	as the map key.
   - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE)
	If current task is a kworker, lookup the above hash
	map using function parameter @owner as the key to get
	its corresponding cgroup id which is then used to get
	a trusted pointer to the cgroup through
	bpf_cgroup_from_id(). This trusted pointer can then
	be passed to bpf_cgrp_storage_get() to finally trigger
	the deadlock issue.
 - B: SEC("tp_btf/sys_enter")
   - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE)
	The only purpose of this prog is to fill Prog A's
	hash map by calling bpf_cgrp_storage_get() for as
	many userspace tasks as possible.

Steps to reproduce:
 - Run A;
 - while (true) { Run B; Destroy B; }

Fix this issue by passing its busy counter to the free procedure so
it can be properly incremented before storage/smap locking.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/6ecb9fa14eec5f15d97c84c[PII_REDACTED]5f6ddfb; https://git.kernel.org/stable/c/c78f4afbd962f43a3989f45f3ca04300252b19b5; https://git.kernel.org/stable/c/fac674d2bd68f3479f27328626b42d1eebd11fef
CVE: CVE-2025-21844
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: client: Add check for next_buffer in receive_encrypted_standard()

Add check for the return value of cifs_buf_get() and cifs_small_buf_get()
in receive_encrypted_standard() to prevent null pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/24e8e4523d3071bc5143b0db9127d511489f7b3b; https://git.kernel.org/stable/c/554736b583f529ee159aa95af9a0cbc12b5ffc96; https://git.kernel.org/stable/c/860ca5e50f73c2a1cef7eefc9d39d04e275417f7
CVE: CVE-2025-21845
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

mtd: spi-nor: sst: Fix SST write failure

'commit 18bcb4aa54ea ("mtd: spi-nor: sst: Factor out common write operation
to `sst_nor_write_data()`")' introduced a bug where only one byte of data
is written, regardless of the number of bytes passed to
sst_nor_write_data(), causing a kernel crash during the write operation.
Ensure the correct number of bytes are written as passed to
sst_nor_write_data().

Call trace:
[   57.400180] ------------[ cut here ]------------
[   57.404842] While writing 2 byte written 1 bytes
[   57.409493] WARNING: CPU: 0 PID: 737 at drivers/mtd/spi-nor/sst.c:187 sst_nor_write_data+0x6c/0x74
[   57.418464] Modules linked in:
[   57.421517] CPU: 0 UID: 0 PID: 737 Comm: mtd_debug Not tainted 6.12.0-g5ad04afd91f9 #30
[   57.429517] Hardware name: Xilinx Versal A2197 Processor board revA - x-prc-02 revA (DT)
[   57.437600] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   57.444557] pc : sst_nor_write_data+0x6c/0x74
[   57.448911] lr : sst_nor_write_data+0x6c/0x74
[   57.453264] sp : ffff80008232bb40
[   57.456570] x29: ffff80008232bb40 x28: [PII_REDACTED] x27: [PII_REDACTED]
[   57.463708] x26:[PII_REDACTED]00ffff x25: [PII_REDACTED] x24: [PII_REDACTED]
[   57.470843] x23: [PII_REDACTED] x22: ffff80008232bbf0 x21: ffff[PII_REDACTED]00
[   57.477978] x20: ffff0008056c0080 x19: [PII_REDACTED] x18: [PII_REDACTED]
[   57.485112] x17: [PII_REDACTED] x16: [PII_REDACTED] x15: ffff80008232b580
[   57.492246] x14: [PII_REDACTED] x13: ffff8000816d1530 x12:[PII_REDACTED]0004a4
[   57.499380] x11:[PII_REDACTED]00018c x10: ffff8000816fd530 x9 : ffff8000816d1530
[   57.506515] x8 : 00000000fffff7ff x7 : ffff8000816fd530 x6 : [PII_REDACTED]
[   57.513649] x5 : [PII_REDACTED] x4 : [PII_REDACTED] x3 : [PII_REDACTED]
[   57.520782] x2 : [PII_REDACTED] x1 : [PII_REDACTED] x0 : ffff0008049b0000
[   57.527916] Call trace:
[   57.530354]  sst_nor_write_data+0x6c/0x74
[   57.534361]  sst_nor_write+0xb4/0x18c
[   57.538019]  mtd_write_oob_std+0x7c/0x88
[   57.541941]  mtd_write_oob+0x70/0xbc
[   57.545511]  mtd_write+0x68/0xa8
[   57.548733]  mtdchar_write+0x10c/0x290
[   57.552477]  vfs_write+0xb4/0x3a8
[   57.555791]  ksys_write+0x74/0x10c
[   57.559189]  __arm64_sys_write+0x1c/0x28
[   57.563109]  invoke_syscall+0x54/0x11c
[   57.566856]  el0_svc_common.constprop.0+0xc0/0xe0
[   57.571557]  do_el0_svc+0x1c/0x28
[   57.574868]  el0_svc+0x30/0xcc
[   57.577921]  el0t_64_sync_handler+0x120/0x12c
[   57.582276]  el0t_64_sync+0x190/0x194
[   57.585933] ---[ end trace [PII_REDACTED] ]---

[pratyush@kernel.org: add Cc stable tag]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/539bd20352832b9244238a055eb169ccf1c41ff6; https://git.kernel.org/stable/c/9553391f32f8c43e12fc7c04e1035160b5ea20bf; https://git.kernel.org/stable/c/bb1accc7e0f688886f0c634f2e878b8ac4ee6a58
CVE: CVE-2025-21846
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

acct: perform last write from workqueue

In [1] it was reported that the acct(2) system call can be used to
trigger NULL deref in cases where it is set to write to a file that
triggers an internal lookup. This can e.g., happen when pointing acc(2)
to /sys/power/resume. At the point the where the write to this file
happens the calling task has already exited and called exit_fs(). A
lookup will thus trigger a NULL-deref when accessing current->fs.

Reorganize the code so that the the final write happens from the
workqueue but with the caller's credentials. This preserves the
(strange) permission model and has almost no regression risk.

This api should stop to exist though.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/56d5f3eba3f5de0efdd556de4ef381e109b973a9; https://git.kernel.org/stable/c/5a59ced8ffc71973d42c82484a719c8f6ac8f7f7; https://git.kernel.org/stable/c/5c928e14a2ccd99462f2351ead627b58075bb736
CVE: CVE-2025-21847
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()

The nullity of sps->cstream should be checked similarly as it is done in
sof_set_stream_data_offset() function.
Assuming that it is not NULL if sps->stream is NULL is incorrect and can
lead to NULL pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/2b3878baf90918a361a3dfd[PII_REDACTED]b1b40b6; https://git.kernel.org/stable/c/62ab1ae5511c59b5f0bf550136ff321331adca9f; https://git.kernel.org/stable/c/6c18f5eb2043ebf4674c08a9690218dc818a11ab
CVE: CVE-2025-21848
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()

Add check for the return value of nfp_app_ctrl_msg_alloc() in
nfp_bpf_cmsg_alloc() to prevent null pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1358d8e07afdf21d49ca6f00c[PII_REDACTED]7e00a; https://git.kernel.org/stable/c/29ccb1e4040da6ff02b7e64efaa2f8e6bf06020d; https://git.kernel.org/stable/c/878e7b11736e062514e58f3b445ff343e6705537
CVE: CVE-2025-21849
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gt: Use spin_lock_irqsave() in interruptible context

spin_lock/unlock() functions used in interrupt contexts could
result in a deadlock, as seen in GitLab issue #13399,
which occurs when interrupt comes in while holding a lock.

Try to remedy the problem by saving irq state before spin lock
acquisition.

v2: add irqs' state save/restore calls to all locks/unlocks in
 signal_irq_work() execution (Maciej)

v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead
 of other lock/unlock calls and add Fixes and Cc tags (Tvrtko);
 change title and commit message

(cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/2bf1f4c129db7a10920655b000f0292f1ee509c2; https://git.kernel.org/stable/c/47ae46ac[PII_REDACTED]e06b78e0dad331e56a4bb4; https://git.kernel.org/stable/c/e49477f7f[PII_REDACTED]1d486ecc7f020d796432e
CVE: CVE-2025-21850
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

nvmet: Fix crash when a namespace is disabled

The namespace percpu counter protects pending I/O, and we can
only safely diable the namespace once the counter drop to zero.
Otherwise we end up with a crash when running blktests/nvme/058
(eg for loop transport):

[ 2352.930426] [  T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc[PII_REDACTED]: 0000 [#1] PREEMPT SMP KASAN PTI
[ 2352.930431] [  T53909] KASAN: null-ptr-deref in range [0x[PII_REDACTED]000028-0x[PII_REDACTED]00002f]
[ 2352.930434] [  T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G        W          6.13.0-rc6 #232
[ 2352.930438] [  T53909] Tainted: [W]=WARN
[ 2352.930440] [  T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
[ 2352.930443] [  T53909] Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]
[ 2352.930449] [  T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180

as the queue is already torn down when calling submit_bio();

So we need to init the percpu counter in nvmet_ns_enable(), and
wait for it to drop to zero in nvmet_ns_disable() to avoid having
I/O pending after the namespace has been disabled.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835, CWE-835
References: https://git.kernel.org/stable/c/[PII_REDACTED]072b71496501b6a0c55ffe8d5092a5; https://git.kernel.org/stable/c/cc0607594f6813342b27c752c6fb6f6eb9980cb5
CVE: CVE-2025-21851
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix softlockup in arena_map_free on 64k page kernel

On an aarch64 kernel with CONFIG_PAGE_SIZE_64KB=y,
arena_htab tests cause a segmentation fault and soft lockup.
The same failure is not observed with 4k pages on aarch64.

It turns out arena_map_free() is calling
apply_to_existing_page_range() with the address returned by
bpf_arena_get_kern_vm_start().  If this address is not page-aligned
the code ends up calling apply_to_pte_range() with that unaligned
address causing soft lockup.

Fix it by round up GUARD_SZ to PAGE_SIZE << 1 so that the
division by 2 in bpf_arena_get_kern_vm_start() returns
a page-aligned value.
CVSS Score: 3.3 (LOW)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/517e8a7835e8cfb398a0aeb0133de50e31cae32b; https://git.kernel.org/stable/c/787d556a3de447e70964a4bdeba9196f62a62b1e; https://git.kernel.org/stable/c/c1f3f3892d4526f18aaeffdb6068ce861e793ee3
CVE: CVE-2025-21852
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net: Add rx_skb of kfree_skb to raw_tp_null_args[].

Yan Zhai reported a BPF prog could trigger a null-ptr-deref [0]
in trace_kfree_skb if the prog does not check if rx_sk is NULL.

Commit c53795d48ee8 ("net: add rx_sk to trace_kfree_skb") added
rx_sk to trace_kfree_skb, but rx_sk is optional and could be NULL.

Let's add kfree_skb to raw_tp_null_args[] to let the BPF verifier
validate such a prog and prevent the issue.

Now we fail to load such a prog:

  libbpf: prog 'drop': -- BEGIN PROG LOAD LOG --
  0: R1=ctx() R10=fp0
  ; int BPF_PROG(drop, struct sk_buff *skb, void *location, @ kfree_skb_sk_null.bpf.c:21
  0: (79) r3 = *(u64 *)(r1 +24)
  func 'kfree_skb' arg3 has btf_id 5253 type STRUCT 'sock'
  1: R1=ctx() R3_w=trusted_ptr_or_null_sock(id=1)
  ; bpf_printk("sk: %d, %d\n", sk, sk->__sk_common.skc_family); @ kfree_skb_sk_null.bpf.c:24
  1: (69) r4 = *(u16 *)(r3 +16)
  R3 invalid mem access 'trusted_ptr_or_null_'
  processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
  -- END PROG LOAD LOG --

Note this fix requires commit 838a10bd2ebf ("bpf: Augment raw_tp
arguments with PTR_MAYBE_NULL").

[0]:
BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
 PF: supervisor read access in kernel mode
 PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
PREEMPT SMP
RIP: 0010:bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d
Call Trace:
 <TASK>
 ? __die+0x1f/0x60
 ? page_fault_oops+0x148/0x420
 ? search_bpf_extables+0x5b/0x70
 ? fixup_exception+0x27/0x2c0
 ? exc_page_fault+0x75/0x170
 ? asm_exc_page_fault+0x22/0x30
 ? bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d
 bpf_trace_run4+0x68/0xd0
 ? unix_stream_connect+0x1f4/0x6f0
 sk_skb_reason_drop+0x90/0x120
 unix_stream_connect+0x1f4/0x6f0
 __sys_connect+0x7f/0xb0
 __x64_sys_connect+0x14/0x20
 do_syscall_64+0x47/0xc30
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/4dba79c1e7aad6620bbb707b6c4459380fd90860; https://git.kernel.org/stable/c/5da7e15fb5a12e78de974d8908f348e279922ce9; https://git.kernel.org/stable/c/f579afacd0a66971fc8481f30d2d377e230a8342
CVE: CVE-2025-21853
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: avoid holding freeze_mutex during mmap operation

We use map->freeze_mutex to prevent races between map_freeze() and
memory mapping BPF map contents with writable permissions. The way we
naively do this means we'll hold freeze_mutex for entire duration of all
the mm and VMA manipulations, which is completely unnecessary. This can
potentially also lead to deadlocks, as reported by syzbot in [0].

So, instead, hold freeze_mutex only during writeability checks, bump
(proactively) "write active" count for the map, unlock the mutex and
proceed with mmap logic. And only if something went wrong during mmap
logic, then undo that "write active" counter increment.

  [0] https://lore.kernel.org/bpf/678dcbc9.050a0220[PII_REDACTED].GAE@google.com/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0d90d9e154144a3a80e9fc0eb9b21b7fc990f68f; https://git.kernel.org/stable/c/271e49f8a58edba65bc2b1250a0abaa98c4bfdbe; https://git.kernel.org/stable/c/29cfda62ab4d92ab94123813db49ab76c1e61b29
CVE: CVE-2025-21854
Published: 2025-03-12
Description: In the Linux kernel, the following vulnerability has been resolved:

sockmap, vsock: For connectible sockets allow only connected

sockmap expects all vsocks to have a transport assigned, which is expressed
in vsock_proto::psock_update_sk_prot(). However, there is an edge case
where an unconnected (connectible) socket may lose its previously assigned
transport. This is handled with a NULL check in the vsock/BPF recv path.

Another design detail is that listening vsocks are not supposed to have any
transport assigned at all. Which implies they are not supported by the
sockmap. But this is complicated by the fact that a socket, before
switching to TCP_LISTEN, may have had some transport assigned during a
failed connect() attempt. Hence, we may end up with a listening vsock in a
sockmap, which blows up quickly:

KASAN: null-ptr-deref in range [0x[PII_REDACTED]000120-0x[PII_REDACTED]000127]
CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+
Workqueue: vsock-loopback vsock_loopback_work
RIP: 0010:vsock_read_skb+0x4b/0x90
Call Trace:
 sk_psock_verdict_data_ready+0xa4/0x2e0
 virtio_transport_recv_pkt+0x1ca8/0x2acc
 vsock_loopback_work+0x27d/0x3f0
 process_one_work+0x846/0x1420
 worker_thread+0x5b3/0xf80
 kthread+0x35a/0x700
 ret_from_fork+0x2d/0x70
 ret_from_fork_asm+0x1a/0x30

For connectible sockets, instead of relying solely on the state of
vsk->transport, tell sockmap to only allow those representing established
connections. This aligns with the behaviour for AF_INET and AF_UNIX.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/22b683217ad2112791a708693cb236507abd637a; https://git.kernel.org/stable/c/8fb5bb169d17cdd12c2dcc2e96830ed487d77a0f; https://git.kernel.org/stable/c/cc9a7832ede53ade1ba9991f0e27314caa4029d8