deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-68303
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/x86: intel: punit_ipc: fix memory corruption

This passes the address of the pointer "&punit_ipcdev" when the intent
was to pass the pointer itself "punit_ipcdev" (without the ampersand).
This means that the:

	complete(&ipcdev->cmd_complete);

in intel_punit_ioc() will write to a wrong memory address corrupting it.
References: https://git.kernel.org/stable/c/15d560cdf5b36c51fffec07ac2a983ab3bff4cb2; https://git.kernel.org/stable/c/3e7442c5802146fd418ba3f68dcb9ca92b5cec83; https://git.kernel.org/stable/c/46e9d6f54184573dae1dcbcf6685a572ba6f4480
CVE: CVE-2025-68304
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_core: lookup hci_conn on RX path on protocol side

The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't
ensure hci_conn* is not concurrently modified/deleted. This locking
appears to be leftover from before conn_hash started using RCU
commit bf4c63252490b ("Bluetooth: convert conn hash to RCU")
and not clear if it had purpose since then.

Currently, there are code paths that delete hci_conn* from elsewhere
than the ordered hdev->workqueue where the RX work runs in. E.g.
commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")
introduced some of these, and there probably were a few others before
it.  It's better to do the locking so that even if these run
concurrently no UAF is possible.

Move the lookup of hci_conn and associated socket-specific conn to
protocol recv handlers, and do them within a single critical section
to cover hci_conn* usage and lookup.

syzkaller has reported a crash that appears to be this issue:

    [Task hdev->workqueue]          [Task 2]
                                    hci_disconnect_all_sync
    l2cap_recv_acldata(hcon)
                                      hci_conn_get(hcon)
                                      hci_abort_conn_sync(hcon)
                                        hci_dev_lock
      hci_dev_lock
                                        hci_conn_del(hcon)
      v-------------------------------- hci_dev_unlock
                                      hci_conn_put(hcon)
      conn = hcon->l2cap_data (UAF)
References: https://git.kernel.org/stable/c/79a2d4678ba90bdba577dc3af88cc900d6dcd5ee; https://git.kernel.org/stable/c/ec74cdf77310c43b01b83ee898a9bd4b4b0b8e93
CVE: CVE-2025-68305
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_sock: Prevent race in socket write iter and sock bind

There is a potential race condition between sock bind and socket write
iter. bind may free the same cmd via mgmt_pending before write iter sends
the cmd, just as syzbot reported in UAF[1].

Here we use hci_dev_lock to synchronize the two, thereby avoiding the
UAF mentioned in [1].

[1]
syzbot reported:
BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316
Read of size 8 at addr ffff[PII_REDACTED]18 by task syz.0.17/5989
Call Trace:
 mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316
 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918
 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
 sock_sendmsg_nosec net/socket.c:727 [inline]
 __sock_sendmsg+0x21c/0x270 net/socket.c:742
 sock_write_iter+0x279/0x360 net/socket.c:1195

Allocated by task 5989:
 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296
 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910
 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
 sock_sendmsg_nosec net/socket.c:727 [inline]
 __sock_sendmsg+0x21c/0x270 net/socket.c:742
 sock_write_iter+0x279/0x360 net/socket.c:1195

Freed by task 5991:
 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]
 mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257
 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477
 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314
References: https://git.kernel.org/stable/c/69fcb0344bc0dd5b13d7e4e98f8b6bf25a6d4ff7; https://git.kernel.org/stable/c/89bb613511cc21ed5ba6bddc1c9b9ae9c0dad392; https://git.kernel.org/stable/c/e90c05fc5bbea956450a05cc3b36b8fa29cf195e
CVE: CVE-2025-68306
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface

When performing reset tests and encountering abnormal card drop issues
that lead to a kernel crash, it is necessary to perform a null check
before releasing resources to avoid attempting to release a null pointer.

<4>[   29.158070] Hardware name: Google Quigon sku196612/196613 board (DT)
<4>[   29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth]
<4>[   29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
<4>[   29.158162] pc : klist_remove+0x90/0x158
<4>[   29.158174] lr : klist_remove+0x88/0x158
<4>[   29.158180] sp : ffffffc0846b3c00
<4>[   29.158185] pmr_save: 000000e0
<4>[   29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058
<4>[   29.158199] x26: dead[PII_REDACTED]00 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0
<4>[   29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290
<4>[   29.158219] x20: [PII_REDACTED] x19: ffffff80cd3e0648 x18: 000000031ec97781
<4>[   29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428
<4>[   29.158238] x14: [PII_REDACTED] x13:[PII_REDACTED]00e380 x12: [PII_REDACTED]
<4>[   29.158248] x11: ffffff80c2a7fd10 x10: [PII_REDACTED] x9 : [PII_REDACTED]
<4>[   29.158257] x8 : [PII_REDACTED] x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d
<4>[   29.158266] x5 : [PII_REDACTED] x4 : [PII_REDACTED] x3 : 2e[PII_REDACTED]636e
<4>[   29.158275] x2 : ffffffdc11afeff8 x1 : [PII_REDACTED] x0 : ffffffdc11be4d0c
<4>[   29.158285] Call trace:
<4>[   29.158290]  klist_remove+0x90/0x158
<4>[   29.158298]  device_release_driver_internal+0x20c/0x268
<4>[   29.158308]  device_release_driver+0x1c/0x30
<4>[   29.158316]  usb_driver_release_interface+0x70/0x88
<4>[   29.158325]  btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)]
<4>[   29.158347]  btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)]
<4>[   29.158361]  hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)]
<4>[   29.158430]  process_scheduled_works+0x258/0x4e8
<4>[   29.158441]  worker_thread+0x300/0x428
<4>[   29.158448]  kthread+0x108/0x1d0
<4>[   29.158455]  ret_from_fork+0x10/0x20
<0>[   29.158467] Code: 9[PII_REDACTED]39d1 f9400268 927ff914 (f9401297)
<4>[   29.158474] ---[ end trace [PII_REDACTED] ]---
<0>[   29.167129] Kernel panic - not syncing: Oops: Fatal exception
<2>[   29.167144] SMP: stopping secondary CPUs
<4>[   29.167158] ------------[ cut here ]------------
References: https://git.kernel.org/stable/c/4015b979767125cf8a2233a145a3b3af78bfd8fb; https://git.kernel.org/stable/c/421e88a0d85782786b7a1764c75518b4845e07b3; https://git.kernel.org/stable/c/faae9f2ea8806f[PII_REDACTED]adbf94689b47b82b
CVE: CVE-2025-68307
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs

The driver lacks the cleanup of failed transfers of URBs. This reduces the
number of available URBs per error by 1. This leads to reduced performance
and ultimately to a complete stop of the transmission.

If the sending of a bulk URB fails do proper cleanup:
- increase netdev stats
- mark the echo_sbk as free
- free the driver's context and do accounting
- wake the send queue
References: https://git.kernel.org/stable/c/1a588c40a422a3663a52f1c5535e8fb6b044167d; https://git.kernel.org/stable/c/4a82072e451eacf24fc66a445e906f5095d215db; https://git.kernel.org/stable/c/516a0cd1c03fa266bb67dd87940a209fd4e53ce7
CVE: CVE-2025-68308
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

can: kvaser_usb: leaf: Fix potential infinite loop in command parsers

The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback`
functions contain logic to zero-length commands. These commands are used
to align data to the USB endpoint's wMaxPacketSize boundary.

The driver attempts to skip these placeholders by aligning the buffer
position `pos` to the next packet boundary using `round_up()` function.

However, if zero-length command is found exactly on a packet boundary
(i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up`
function will return the unchanged value of `pos`. This prevents `pos`
to be increased, causing an infinite loop in the parsing logic.

This patch fixes this in the function by using `pos + 1` instead.
This ensures that even if `pos` is on a boundary, the calculation is
based on `pos + 1`, forcing `round_up()` to always return the next
aligned boundary.
References: https://git.kernel.org/stable/c/028e89c7e8b4346302e88df01cc50e0a1f05791a; https://git.kernel.org/stable/c/0897cea266e39166a36111059ba147192b36592f; https://git.kernel.org/stable/c/0c73772cd2b8cc108d5f5334de89ad648d89b9ec
CVE: CVE-2025-68309
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI/AER: Fix NULL pointer access by aer_info

The kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info->xxx
will result in kernel panic. Fix it.
References: https://git.kernel.org/stable/c/0a27bdb14b028fed30a10cec2f945c38cb5ca4fa; https://git.kernel.org/stable/c/6618243bcc3f60825f761a41ed65fef9fe97eb25
CVE: CVE-2025-68311
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

tty: serial: ip22zilog: Use platform device for probing

After commit 84a9582fd203 ("serial: core: Start managing serial controllers
to enable runtime PM") serial drivers need to provide a device in
struct uart_port.dev otherwise an oops happens. To fix this issue
for ip22zilog driver switch driver to a platform driver and setup
the serial device in sgi-ip22 code.
References: https://git.kernel.org/stable/c/3fc36ae6abd263a5cbf93b2f5539eccc1fc753f7; https://git.kernel.org/stable/c/460e0dc9af2d7790d5194c6743d79f9b77b58836; https://git.kernel.org/stable/c/77a196ca904d66c8372aa8fbfc1c4ae3a66dee2e
CVE: CVE-2025-68312
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

usbnet: Prevents free active kevent

The root cause of this issue are:
1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);
put the kevent work in global workqueue. However, the kevent has not yet
been scheduled when the usbnet device is unregistered. Therefore, executing
free_netdev() results in the "free active object (kevent)" error reported
here.

2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(),
if the usbnet device is up, ndo_stop() is executed to cancel the kevent.
However, because the device is not up, ndo_stop() is not executed.

The solution to this problem is to cancel the kevent before executing
free_netdev().
References: https://git.kernel.org/stable/c/285d4b953f2ca03c358f986718dd89ee9bde632e; https://git.kernel.org/stable/c/2ce1de32e05445d77fc056f6ff8339cfb78a5f84; https://git.kernel.org/stable/c/3a10619fdefd3051aeb14860e4d4335529b4e94d
CVE: CVE-2025-68313
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/CPU/AMD: Add RDSEED fix for Zen5

There's an issue with RDSEED's 16-bit and 32-bit register output
variants on Zen5 which return a random value of 0 "at a rate inconsistent
with randomness while incorrectly signaling success (CF=1)". Search the
web for AMD-SB-7055 for more detail.

Add a fix glue which checks microcode revisions.

  [ bp: Add microcode revisions checking, rewrite. ]
References: https://git.kernel.org/stable/c/36ff93e66d0efc46e39fab536a9feec968daa766; https://git.kernel.org/stable/c/607b9fb2ce248cc5b633c5949e[PII_REDACTED]c152; https://git.kernel.org/stable/c/e980de2ff109dacb6d9d3a77f01b27c467115ecb
CVE: CVE-2025-68314
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm: make sure last_fence is always updated

Update last_fence in the vm-bind path instead of kernel managed path.

last_fence is used to wait for work to finish in vm_bind contexts but not
used for kernel managed contexts.

This fixes a bug where last_fence is not waited on context close leading
to faults as resources are freed while in use.

Patchwork: https://patchwork.freedesktop.org/patch/680080/
References: https://git.kernel.org/stable/c/86404a9e3013d814a772ac407573be5d3cd4ee0d; https://git.kernel.org/stable/c/8ee817ceafba266d9c6f3a09babd2ac7441d9a2b
CVE: CVE-2025-68315
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to detect potential corrupted nid in free_nid_list

As reported, on-disk footer.ino and footer.nid is the same and
out-of-range, let's add sanity check on f2fs_alloc_nid() to detect
any potential corruption in free_nid_list.
References: https://git.kernel.org/stable/c/6b9525596a83cd5b7bbc2c7bd5f9ad9cf5ad60fa; https://git.kernel.org/stable/c/8fc6056dcf79937c46c97fa4996cda65956437a9; https://git.kernel.org/stable/c/adbcb34f03abb89e681a5907c4c3ce4bf224991d
CVE: CVE-2025-68316
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Fix invalid probe error return value

After DME Link Startup, the error return value is set to the MIPI UniPro
GenericErrorCode which can be 0 (SUCCESS) or 1 (FAILURE).  Upon failure
during driver probe, the error code 1 is propagated back to the driver
probe function which must return a negative value to indicate an error,
but 1 is not negative, so the probe is considered to be successful even
though it failed.  Subsequently, removing the driver results in an oops
because it is not in a valid state.

This happens because none of the callers of ufshcd_init() expect a
non-negative error code.

Fix the return value and documentation to match actual usage.
References: https://git.kernel.org/stable/c/a2b32bc1d9e359a9f90d0de6af16699facb10935; https://git.kernel.org/stable/c/df96dbe1af7f6591c09f862f1226d3619b07e1b6
CVE: CVE-2025-68317
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/zctx: check chained notif contexts

Send zc only links ubuf_info for requests coming from the same context.
There are some ambiguous syz reports, so let's check the assumption on
notification completion.
References: https://git.kernel.org/stable/c/aaafd17d3f4be2c15539359a5b4bfa00237f687f; https://git.kernel.org/stable/c/ab3ea6eac5f45669b091309f592c4ea324003053; https://git.kernel.org/stable/c/d664a3ce3a604231a0b144c152a3755d03b18b60
CVE: CVE-2025-68318
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: thead: th1520-ap: set all AXI clocks to CLK_IS_CRITICAL

The AXI crossbar of TH1520 has no proper timeout handling, which means
gating AXI clocks can easily lead to bus timeout and thus system hang.

Set all AXI clock gates to CLK_IS_CRITICAL. All these clock gates are
ungated by default on system reset.

In addition, convert all current CLK_IGNORE_UNUSED usage to
CLK_IS_CRITICAL to prevent unwanted clock gating.
References: https://git.kernel.org/stable/c/bdec5e01fc2f3114d1fb1daeb1000911d783c4ae; https://git.kernel.org/stable/c/c567bc5fc68c4388c00e11fc65fd14fe86b52070
CVE: CVE-2025-68319
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

netconsole: Acquire su_mutex before navigating configs hierarchy

There is a race between operations that iterate over the userdata
cg_children list and concurrent add/remove of userdata items through
configfs. The update_userdata() function iterates over the
nt->userdata_group.cg_children list, and count_extradata_entries() also
iterates over this same list to count nodes.

Quoting from Documentation/filesystems/configfs.rst:
> A subsystem can navigate the cg_children list and the ci_parent pointer
> to see the tree created by the subsystem.  This can race with configfs'
> management of the hierarchy, so configfs uses the subsystem mutex to
> protect modifications.  Whenever a subsystem wants to navigate the
> hierarchy, it must do so under the protection of the subsystem
> mutex.

Without proper locking, if a userdata item is added or removed
concurrently while these functions are iterating, the list can be
accessed in an inconsistent state. For example, the list_for_each() loop
can reach a node that is being removed from the list by list_del_init()
which sets the nodes' .next pointer to point to itself, so the loop will
never end (or reach the WARN_ON_ONCE in update_userdata() ).

Fix this by holding the configfs subsystem mutex (su_mutex) during all
operations that iterate over cg_children.
This includes:
- userdatum_value_store() which calls update_userdata() to iterate over
  cg_children
- All sysdata_*_enabled_store() functions which call
  count_extradata_entries() to iterate over cg_children

The su_mutex must be acquired before dynamic_netconsole_mutex to avoid
potential lock ordering issues, as configfs operations may already hold
su_mutex when calling into our code.
References: https://git.kernel.org/stable/c/d7d2fcf7ae31471b4e08b7e448b8fd0ec2e06a1b; https://git.kernel.org/stable/c/ff70aa7e8cf05745fdba7258952a8bedf33ea336
CVE: CVE-2025-68320
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

lan966x: Fix sleeping in atomic context

The following warning was seen when we try to connect using ssh to the device.

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear
preempt_count: 1, expected: 0
INFO: lockdep is turned off.
CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G        W           6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE
Tainted: [W]=WARN
Hardware name: Generic DT based system
Call trace:
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x7c/0xac
 dump_stack_lvl from __might_resched+0x16c/0x2b0
 __might_resched from __mutex_lock+0x64/0xd34
 __mutex_lock from mutex_lock_nested+0x1c/0x24
 mutex_lock_nested from lan966x_stats_get+0x5c/0x558
 lan966x_stats_get from dev_get_stats+0x40/0x43c
 dev_get_stats from dev_seq_printf_stats+0x3c/0x184
 dev_seq_printf_stats from dev_seq_show+0x10/0x30
 dev_seq_show from seq_read_iter+0x350/0x4ec
 seq_read_iter from seq_read+0xfc/0x194
 seq_read from proc_reg_read+0xac/0x100
 proc_reg_read from vfs_read+0xb0/0x2b0
 vfs_read from ksys_read+0x6c/0xec
 ksys_read from ret_fast_syscall+0x0/0x1c
Exception stack(0xf0b11fa8 to 0xf0b11ff0)
1fa0:                   [PII_REDACTED] 00000008 be9048d8 [PII_REDACTED]
1fc0: [PII_REDACTED] [PII_REDACTED] be[PII_REDACTED]001e [PII_REDACTED]
1fe0: 0005404c be9048c0 00018684 b6ec2cd8

It seems that we are using a mutex in a atomic context which is wrong.
Change the mutex with a spinlock.
References: https://git.kernel.org/stable/c/0216721ce71252f60d89af49c8dff613358058d3; https://git.kernel.org/stable/c/3ac743c60ec502163c435712d527eeced8d83348; https://git.kernel.org/stable/c/5a5d2f7727752b64d13263eacd9f8d08a322e662
CVE: CVE-2025-68321
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

page_pool: always add GFP_NOWARN for ATOMIC allocations

Driver authors often forget to add GFP_NOWARN for page allocation
from the datapath. This is annoying to users as OOMs are a fact
of life, and we pretty much expect network Rx to hit page allocation
failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations
by default.
References: https://git.kernel.org/stable/c/0ec2cd5c58793d0c622797cd5fbe26634b357210; https://git.kernel.org/stable/c/3671a[PII_REDACTED]228ae44e096eb144bca75f8dc; https://git.kernel.org/stable/c/7613c06ffa89c1e2266fb532e23ef7dfdf269d73
CVE: CVE-2025-68322
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

parisc: Avoid crash due to unaligned access in unwinder

Guenter Roeck reported this kernel crash on his emulated B160L machine:

Starting network: udhcpc: started, v1.36.1
 Backtrace:
  [<104320d4>] unwind_once+0x1c/0x5c
  [<10434a00>] walk_stackframe.isra.0+0x74/0xb8
  [<10434a6c>] arch_stack_walk+0x28/0x38
  [<104e5efc>] stack_trace_save+0x48/0x5c
  [<105d1bdc>] set_track_prepare+0x44/0x6c
  [<105d9c80>] ___slab_alloc+0xfc4/0x1024
  [<105d9d38>] __slab_alloc.isra.0+0x58/0x90
  [<105dc80c>] kmem_cache_alloc_noprof+0x2ac/0x4a0
  [<105b8e54>] __anon_vma_prepare+0x60/0x280
  [<105a823c>] __vmf_anon_prepare+0x68/0x94
  [<105a8b34>] do_wp_page+0x8cc/0xf10
  [<105aad88>] handle_mm_fault+0x6c0/0xf08
  [<10425568>] do_page_fault+0x110/0x440
  [<10427938>] handle_interruption+0x184/0x748
  [<11178398>] schedule+0x4c/0x190
  BUG: spinlock recursion on CPU#0, ifconfig/2420
  lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0

While creating the stack trace, the unwinder uses the stack pointer to guess
the previous frame to read the previous stack pointer from memory.  The crash
happens, because the unwinder tries to read from unaligned memory and as such
triggers the unalignment trap handler which then leads to the spinlock
recursion and finally to a deadlock.

Fix it by checking the alignment before accessing the memory.
References: https://git.kernel.org/stable/c/009270208f76456c2cefcd565da263b90bb2eadb; https://git.kernel.org/stable/c/9ac1f44723f26881b9fe7e69c7bc25397b879155; https://git.kernel.org/stable/c/fd9f30d1038ee1624baa17a6ff11effe5f7617cb
CVE: CVE-2023-53894
Published: 2025-12-16
Description: phpfm 1.7.9 contains an authentication bypass vulnerability that allows attackers to log in by exploiting loose type comparison in password hash validation. Attackers can craft specific password hashes beginning with 0e or 00e to bypass authentication and upload malicious PHP files to the server.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-1390
References: https://www.dulldusk.com/phpfm/; https://www.exploit-db.com/exploits/51594; https://www.vulncheck.com/advisories/phpfm-authentication-bypass-via-type-juggling-vulnerability
CVE: CVE-2023-53895
Published: 2025-12-16
Description: PimpMyLog 1.7.14 contains an improper access control vulnerability that allows remote attackers to create admin accounts without authorization through the configuration endpoint. Attackers can exploit the unsanitized username field to inject malicious JavaScript, create a hidden backdoor account, and potentially access sensitive server-side log information and environmental variables.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-285
References: https://github.com/potsky/PimpMyLog; https://www.exploit-db.com/exploits/51593; https://www.pimpmylog.com/
CVE: CVE-2023-53897
Published: 2025-12-16
Description: Rukovoditel 3.4.1 contains multiple stored cross-site scripting vulnerabilities that allow authenticated attackers to inject malicious scripts. Attackers can insert XSS payloads in project task comments to execute arbitrary JavaScript in victim browsers.
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79
References: https://www.exploit-db.com/exploits/51548; https://www.rukovoditel.net/; https://www.vulncheck.com/advisories/rukovoditel-multiple-stored-cross-site-scripting-via-comments
CVE: CVE-2023-53898
Published: 2025-12-16
Description: Rukovoditel 3.4.1 contains a stored cross-site scripting vulnerabilities that allow authenticated attackers to inject malicious scripts. Attackers can insert iframe and script payloads in application copyright text to execute arbitrary JavaScript in victim browsers.
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79
References: https://www.exploit-db.com/exploits/51548; https://www.rukovoditel.net/; https://www.vulncheck.com/advisories/rukovoditel-multiple-stored-cross-site-scripting-via-configuration