deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38076
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

alloc_tag: allocate percpu counters for module tags dynamically

When a module gets unloaded it checks whether any of its tags are still in
use and if so, we keep the memory containing module's allocation tags
alive until all tags are unused.  However percpu counters referenced by
the tags are freed by free_module().  This will lead to UAF if the memory
allocated by a module is accessed after module was unloaded.

To fix this we allocate percpu counters for module allocation tags
dynamically and we keep it alive for tags which are still in use after
module unloading.  This also removes the requirement of a larger
PERCPU_MODULE_RESERVE when memory allocation profiling is enabled because
percpu memory for counters does not need to be reserved anymore.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/12ca42c237756182aad8ab04654c952765cb9061; https://git.kernel.org/stable/c/3cc733e6d96c938d2b82be96858a0ab900eb6fdc
CVE: CVE-2025-38077
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store()

If the 'buf' array received from the user contains an empty string, the
'length' variable will be zero. Accessing the 'buf' array element with
index 'length - 1' will result in a buffer overflow.

Add a check for an empty string.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/4e89a4077490f52cde652d17e32519b666abf3a6; https://git.kernel.org/stable/c/60bd13f8c4b3de2c910ae1cdbef85b9bbc9685f5; https://git.kernel.org/stable/c/8594a123cfa23d708582dc6fb36da34479ef8a5b
CVE: CVE-2025-38078
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Fix race of buffer access at PCM OSS layer

The PCM OSS layer tries to clear the buffer with the silence data at
initialization (or reconfiguration) of a stream with the explicit call
of snd_pcm_format_set_silence() with runtime->dma_area.  But this may
lead to a UAF because the accessed runtime->dma_area might be freed
concurrently, as it's performed outside the PCM ops.

For avoiding it, move the code into the PCM core and perform it inside
the buffer access lock, so that it won't be changed during the
operation.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/10217da9644ae75cea7330f902c35fc5ba78bbbf; https://git.kernel.org/stable/c/74d90875f3d43f3eff0e9861c[PII_REDACTED]d3455; https://git.kernel.org/stable/c/8170d8ec4efd0be352c14cb61f374e30fb0c2a25
CVE: CVE-2025-38079
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: algif_hash - fix double free in hash_accept

If accept(2) is called on socket type algif_hash with
MSG_MORE flag set and crypto_ahash_import fails,
sk2 is freed. However, it is also freed in af_alg_release,
leading to slab-use-after-free error.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/0346f4b742345d1c733c977f3a7aef5a6419a967; https://git.kernel.org/stable/c/134daaba93193df9e988524b5cd2f52d15eb1993; https://git.kernel.org/stable/c/2f45a8d64fb4ed4830a4b3273834ecd6ca504896
CVE: CVE-2025-38080
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Increase block_sequence array size

[Why]
It's possible to generate more than 50 steps in hwss_build_fast_sequence,
for example with a 6-pipe asic where all pipes are in one MPC chain. This
overflows the block_sequence buffer and corrupts block_sequence_steps,
causing a crash.

[How]
Expand block_sequence to 100 items. A naive upper bound on the possible
number of steps for a 6-pipe asic, ignoring the potential for steps to be
mutually exclusive, is 91 with current code, therefore 100 is sufficient.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3a7810c212bcf2f722671dadf4b23ff70a7d23ee; https://git.kernel.org/stable/c/bf1666072e7482317cf[PII_REDACTED]482a21a62c7; https://git.kernel.org/stable/c/de67e80ab48f1f[PII_REDACTED]7a2fa3c1471a7757
CVE: CVE-2025-38081
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

spi-rockchip: Fix register out of bounds access

Do not write native chip select stuff for GPIO chip selects.
GPIOs can be numbered much higher than native CS.
Also, it makes no sense.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/254e04ec799c1ff8c1e2bd08a57c6a849895d6ff; https://git.kernel.org/stable/c/4a120221661fcecb253448d7b041a52d47f1d91f; https://git.kernel.org/stable/c/7a874e8b54ea21094f7fd2d428b164394c6cb316
CVE: CVE-2025-38082
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

gpio: virtuser: fix potential out-of-bound write

If the caller wrote more characters, count is truncated to the max
available space in "simple_write_to_buffer". Check that the input
size does not exceed the buffer size. Write a zero termination
afterwards.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/7118be7c6072f[PII_REDACTED]3fdd1563b8d56377c; https://git.kernel.org/stable/c/afe090366f470f77e140ff3407db813f57852c04; https://git.kernel.org/stable/c/b96feaaa0fda1e3871b438143c3446954b32d3a7
CVE: CVE-2025-5237
Published: 2025-06-18
Description: The Target Video Easy Publish plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘width’ parameter in all versions up to, and including, 3.8.5 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
References: https://plugins.trac.wordpress.org/browser/brid-video-easy-publish/trunk/lib/BridShortcode.php#L221; https://plugins.trac.wordpress.org/changeset/3309639/; https://wordpress.org/plugins/brid-video-easy-publish/#developers
CVE: CVE-2025-6086
Published: 2025-06-18
Description: The CSV Me plugin for WordPress is vulnerable to arbitrary file uploads due to insufficient file type validation in the 'csv_me_options_page' function in all versions up to, and including, 2.0. This makes it possible for authenticated attackers, with Administrator-level access and above, to upload arbitrary files on the affected site's server which may make remote code execution possible.
CVSS Score: 7.2 (HIGH)
CWE: CWE-434
References: https://plugins.trac.wordpress.org/browser/csv-me/trunk/csv_me_index.php#L49; https://www.wordfence.com/threat-intel/vulnerabilities/id/83bf3f3d-49f1-473a-a9ee-d78eb8981ad3?source=cve
CVE: CVE-2022-49934
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: Fix UAF in ieee80211_scan_rx()

ieee80211_scan_rx() tries to access scan_req->flags after a
null check, but a UAF is observed when the scan is completed
and __ieee80211_scan_completed() executes, which then calls
cfg80211_scan_done() leading to the freeing of scan_req.

Since scan_req is rcu_dereference()'d, prevent the racing in
__ieee80211_scan_completed() by ensuring that from mac80211's
POV it is no longer accessed from an RCU read critical section
before we call cfg80211_scan_done().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4abc8c07a065ecf771827bde3c63fbbe4aa0c08b; https://git.kernel.org/stable/c/5d20c6f932f2758078d[PII_REDACTED]c894fe353e7; https://git.kernel.org/stable/c/60deb9f10eec5c6a20252ed36238b55d8b614a2c
CVE: CVE-2022-49935
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

dma-buf/dma-resv: check if the new fence is really later

Previously when we added a fence to a dma_resv object we always
assumed the the newer than all the existing fences.

With Jason's work to add an UAPI to explicit export/import that's not
necessary the case any more. So without this check we would allow
userspace to force the kernel into an use after free error.

Since the change is very small and defensive it's probably a good
idea to backport this to stable kernels as well just in case others
are using the dma_resv object in the same way.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/a3f7c10a269d5b77dd5822ade822643ced3057f0; https://git.kernel.org/stable/c/c4c798fe98adceb642050819cb57cbc8f5c27870
CVE: CVE-2022-49936
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: core: Prevent nested device-reset calls

Automatic kernel fuzzing revealed a recursive locking violation in
usb-storage:

============================================
WARNING: possible recursive locking detected
5.18.0 #3 Not tainted
--------------------------------------------
kworker/1:3/1205 is trying to acquire lock:
ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230

but task is already holding lock:
ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230

...

stack backtrace:
CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_deadlock_bug kernel/locking/lockdep.c:2988 [inline]
check_deadlock kernel/locking/lockdep.c:3031 [inline]
validate_chain kernel/locking/lockdep.c:3816 [inline]
__lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053
lock_acquire kernel/locking/lockdep.c:5665 [inline]
lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109
r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622
usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458
device_remove drivers/base/dd.c:545 [inline]
device_remove+0x11f/0x170 drivers/base/dd.c:537
__device_release_driver drivers/base/dd.c:1222 [inline]
device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248
usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627
usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118
usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114

This turned out not to be an error in usb-storage but rather a nested
device reset attempt.  That is, as the rtl8712 driver was being
unbound from a composite device in preparation for an unrelated USB
reset (that driver does not have pre_reset or post_reset callbacks),
its ->remove routine called usb_reset_device() -- thus nesting one
reset call within another.

Performing a reset as part of disconnect processing is a questionable
practice at best.  However, the bug report points out that the USB
core does not have any protection against nested resets.  Adding a
reset_in_progress flag and testing it will prevent such errors in the
future.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1b[PII_REDACTED]4c7f9afb[PII_REDACTED]18a753d372; https://git.kernel.org/stable/c/9c6d778800b921bde3bff3cff5003d1650f942d1; https://git.kernel.org/stable/c/abe3cfb7a7c8e907b312c7dbd7bf4d142b745aa8
CVE: CVE-2022-49937
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mceusb: Use new usb_control_msg_*() routines

Automatic kernel fuzzing led to a WARN about invalid pipe direction in
the mceusb driver:

------------[ cut here ]------------
usb 6-1: BOGUS control dir, pipe 80000380 doesn't match bRequestType 40
WARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410
usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410
Modules linked in:
CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410
Code: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8
44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0b
e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41
RSP: 0018:ffffc900032becf0 EFLAGS: 00010282
RAX: [PII_REDACTED] RBX: ffff8881100f3058 RCX: [PII_REDACTED]
RDX: ffffc[PII_REDACTED]0 RSI: ffff888114c6d580 RDI: fffff52000657d90
RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: ffffed1023504ef1 R12: ffff888105ad9000
R13: [PII_REDACTED] R14: [PII_REDACTED] R15: ffff88810ba96500
FS: [PII_REDACTED](0000) GS:ffff88811a800000(0000) knlGS:[PII_REDACTED]
CS: 0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4:[PII_REDACTED]350ef0
Call Trace:
<TASK>
usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153
mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline]
mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807

The reason for the warning is clear enough; the driver sends an
unusual read request on endpoint 0 but does not set the USB_DIR_IN bit
in the bRequestType field.

More importantly, the whole situation can be avoided and the driver
simplified by converting it over to the relatively new
usb_control_msg_recv() and usb_control_msg_send() routines.  That's
what this fix does.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/587f793c64d99d92be8ef01c4c69d885a3f2edb6; https://git.kernel.org/stable/c/608e58a0f[PII_REDACTED]131f5f68a3fce1d3f5316; https://git.kernel.org/stable/c/75913c562f5ba4cf397d835c63f443879167c6f6
CVE: CVE-2022-49938
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix small mempool leak in SMB2_negotiate()

In some cases of failure (dialect mismatches) in SMB2_negotiate(), after
the request is sent, the checks would return -EIO when they should be
rather setting rc = -EIO and jumping to neg_exit to free the response
buffer from mempool.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/27893dfc1285f80f80f46b3b8c95f5d15d2e66d0; https://git.kernel.org/stable/c/38a6b469bf22f153282fbe7d702a24e9eb43f50e; https://git.kernel.org/stable/c/9e3c9efa7caf16e5acc05eab5e4d0a714e1610b0
CVE: CVE-2022-49939
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

binder: fix UAF of ref->proc caused by race condition

A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the
reference for a node. In this case, the target proc normally releases
the failed reference upon close as expected. However, if the target is
dying in parallel the call will race with binder_deferred_release(), so
the target could have released all of its references by now leaving the
cleanup of the new failed reference unhandled.

The transaction then ends and the target proc gets released making the
ref->proc now a dangling pointer. Later on, ref->node is closed and we
attempt to take spin_lock(&ref->proc->inner_lock), which leads to the
use-after-free bug reported below. Let's fix this by cleaning up the
failed reference on the spot instead of relying on the target to do so.

  ==================================================================
  BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150
  Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590

  CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10
  Hardware name: linux,dummy-virt (DT)
  Workqueue: events binder_deferred_func
  Call trace:
   dump_backtrace.part.0+0x1d0/0x1e0
   show_stack+0x18/0x70
   dump_stack_lvl+0x68/0x84
   print_report+0x2e4/0x61c
   kasan_report+0xa4/0x110
   kasan_check_range+0xfc/0x1a4
   __kasan_check_write+0x3c/0x50
   _raw_spin_lock+0xa8/0x150
   binder_deferred_func+0x5e0/0x9b0
   process_one_work+0x38c/0x5f0
   worker_thread+0x9c/0x694
   kthread+0x188/0x190
   ret_from_fork+0x10/0x20
CVSS Score: 7.0 (HIGH)
CWE: CWE-362, CWE-416
References: https://git.kernel.org/stable/c/06e5b43ca4dab06a92bf4c2f33766e6fb11b880a; https://git.kernel.org/stable/c/229f47603dd306bc0eb1a831439adb8e48bb0eae; https://git.kernel.org/stable/c/30d0901b307f27d36b2655fb3048cf31ee0e89c0
CVE: CVE-2022-49940
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf()

A null pointer dereference can happen when attempting to access the
"gsm->receive()" function in gsmld_receive_buf(). Currently, the code
assumes that gsm->recieve is only called after MUX activation.
Since the gsmld_receive_buf() function can be accessed without the need to
initialize the MUX, the gsm->receive() function will not be set and a
NULL pointer dereference will occur.

Fix this by avoiding the call to "gsm->receive()" in case the function is
not initialized by adding a sanity check.

Call Trace:
 <TASK>
 gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861
 tiocsti drivers/tty/tty_io.c:2293 [inline]
 tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/309aea4b6b813f6678c3a547cfd7fe3a76ffa976; https://git.kernel.org/stable/c/5a82cf64f8ad63caf6bf115642ce44ddbc64311e; https://git.kernel.org/stable/c/5aa37f9510345a812c0998bcbbc4d88d1dcc4d8b
CVE: CVE-2022-49941
Published: 2025-06-18
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2022-49942
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: Don't finalize CSA in IBSS mode if state is disconnected

When we are not connected to a channel, sending channel "switch"
announcement doesn't make any sense.

The BSS list is empty in that case. This causes the for loop in
cfg80211_get_bss() to be bypassed, so the function returns NULL
(check line 1424 of net/wireless/scan.c), causing the WARN_ON()
in ieee80211_ibss_csa_beacon() to get triggered (check line 500
of net/mac80211/ibss.c), which was consequently reported on the
syzkaller dashboard.

Thus, check if we have an existing connection before generating
the CSA beacon in ieee80211_ibss_finish_csa().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/15bc8966b6d3a5b9bfe4c9facfa02f2b69b1e5f0; https://git.kernel.org/stable/c/1691a48aef0a82d1754b9853dae7e3f5cacdf70b; https://git.kernel.org/stable/c/552ba102a6898630a7d16887f29e606d6fabe508
CVE: CVE-2022-49944
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

Revert "usb: typec: ucsi: add a common function ucsi_unregister_connectors()"

The recent commit 87d0e2f41b8c ("usb: typec: ucsi: add a common
function ucsi_unregister_connectors()") introduced a regression that
caused NULL dereference at reading the power supply sysfs.  It's a
stale sysfs entry that should have been removed but remains with NULL
ops.  The commit changed the error handling to skip the entries after
a NULL con->wq, and this leaves the power device unreleased.

For addressing the regression, the straight revert is applied here.
Further code improvements can be done from the scratch again.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3d4044c9e6d2e3f11f1f8b5e0ee8647d3eb1afad; https://git.kernel.org/stable/c/5f73aa2cf8bef4a39baa1591c3144ede4788826e
CVE: CVE-2022-49946
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: bcm: rpi: Prevent out-of-bounds access

The while loop in raspberrypi_discover_clocks() relies on the assumption
that the id of the last clock element is zero. Because this data comes
from the Videocore firmware and it doesn't guarantuee such a behavior
this could lead to out-of-bounds access. So fix this by providing
a sentinel element.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/bc163555603e4ae9c817675ad80d618a4cdbfa2d; https://git.kernel.org/stable/c/c8b04b731d[PII_REDACTED]1ebdca4ac715f95e0ea4; https://git.kernel.org/stable/c/fcae47b2d23c81603b01f56cf8db63ed64599d34
CVE: CVE-2022-49947
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

binder: fix alloc->vma_vm_mm null-ptr dereference

Syzbot reported a couple issues introduced by commit 44e602b4e52f
("binder_alloc: add missing mmap_lock calls when using the VMA"), in
which we attempt to acquire the mmap_lock when alloc->vma_vm_mm has not
been initialized yet.

This can happen if a binder_proc receives a transaction without having
previously called mmap() to setup the binder_proc->alloc space in [1].
Also, a similar issue occurs via binder_alloc_print_pages() when we try
to dump the debugfs binder stats file in [2].

Sample of syzbot's crash report:
  ==================================================================
  KASAN: null-ptr-deref in range [0x[PII_REDACTED]000128-0x[PII_REDACTED]00012f]
  CPU: 0 PID: 3755 Comm: syz-executor229 Not tainted 6.0.0-rc1-next-20220819-syzkaller #0
  syz-executor229[3755] cmdline: ./syz-executor[PII_REDACTED]
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
  RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923
  [...]
  Call Trace:
   <TASK>
   lock_acquire kernel/locking/lockdep.c:5666 [inline]
   lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631
   down_read+0x98/0x450 kernel/locking/rwsem.c:1499
   mmap_read_lock include/linux/mmap_lock.h:117 [inline]
   binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline]
   binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593
   binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199
   binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986
   binder_ioctl_write_read drivers/android/binder.c:5036 [inline]
   binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:870 [inline]
   __se_sys_ioctl fs/ioctl.c:856 [inline]
   __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856
   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
   do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
   entry_SYSCALL_64_after_hwframe+0x63/0xcd
   [...]
  ==================================================================

Fix these issues by setting up alloc->vma_vm_mm pointer during open()
and caching directly from current->mm. This guarantees we have a valid
reference to take the mmap_lock during scenarios described above.

[1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459
[2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1da52815d5f1b654c89044db0cdc6adce43da1f1; https://git.kernel.org/stable/c/81203ab7a6ef843a2b904a0a494f28c457d44d27; https://git.kernel.org/stable/c/b2a97babb0a510f8921891f9e70c5a5ef33cadac