deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-54307
Published: 2025-12-04
Description: An issue was discovered in the Thermo Fisher Torrent Suite Django application 5.18.1. The /configure/plugins/plugin/upload/zip/ and /configure/newupdates/offline/bundle/upload/ endpoints allow low-privilege users to upload ZIP files to the server. The plupload_file_upload function handles these file uploads and constructs the destination file path by using either the name parameter or the uploaded filename, neither of which is properly sanitized. The file extension is extracted by splitting the filename, and a format string is used to construct the final file path, leaving the destination path vulnerable to path traversal. An authenticated attacker with network connectivity can write arbitrary files to the server, enabling remote code execution after overwriting an executable file. An example is the pdflatex executable, which is executed through subprocess.Popen in the write_report_pdf function after requests to a /report/latex/(\d+).pdf endpoint.
CVSS Score: 8.8 (HIGH)
CWE: CWE-22
References: https://assets.thermofisher.com/TFS-Assets/LSG/manuals/MAN0026163-Torrent-Suite-5.18-UG.pdf; https://documents.thermofisher.com/TFS-Assets/CORP/Product-Guides/Ion_OneTouch_2_and_Torrent_Suite_Software.pdf; https://www.thermofisher.com/us/en/home/life-science/sequencing/next-generation-sequencing/ion-torrent-next-generation-sequencing-workflow/ion-torrent-next-generation-sequencing-data-analysis-workflow/ion-torrent-suite-software.html
CVE: CVE-2025-65346
Published: 2025-12-04
Description: alexusmai laravel-file-manager 3.3.1 and below is vulnerable to Directory Traversal. The unzip/extraction functionality improperly allows archive contents to be written to arbitrary locations on the filesystem due to insufficient validation of extraction paths.
CVSS Score: 9.1 (CRITICAL)
CWE: CWE-22
References: https://github.com/Theethat-Thamwasin/CVE-2025-65346; https://github.com/alexusmai/laravel-file-manager; https://github.com/Theethat-Thamwasin/CVE-2025-65346/blob/main/POC-CVE-65346.md
CVE: CVE-2025-14024
Published: 2025-12-04
Description: Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. Reason: This candidate was issued in error. Notes: All references and descriptions in this candidate have been removed to prevent accidental usage.
CVE: CVE-2025-40223
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

most: usb: Fix use-after-free in hdm_disconnect

hdm_disconnect() calls most_deregister_interface(), which eventually
unregisters the MOST interface device with device_unregister(iface->dev).
If that drops the last reference, the device core may call release_mdev()
immediately while hdm_disconnect() is still executing.

The old code also freed several mdev-owned allocations in
hdm_disconnect() and then performed additional put_device() calls.
Depending on refcount order, this could lead to use-after-free or
double-free when release_mdev() ran (or when unregister paths also
performed puts).

Fix by moving the frees of mdev-owned allocations into release_mdev(),
so they happen exactly once when the device is truly released, and by
dropping the extra put_device() calls in hdm_disconnect() that are
redundant after device_unregister() and most_deregister_interface().

This addresses the KASAN slab-use-after-free reported by syzbot in
hdm_disconnect(). See report and stack traces in the bug link below.
References: https://git.kernel.org/stable/c/33daf469f5294b9d07c4fc98216cace9f4f34cc6; https://git.kernel.org/stable/c/3a3b8e89c7201c5b3b76ac4a4069d1adde1477d6; https://git.kernel.org/stable/c/4b[PII_REDACTED]ef0d935ed2faa2ea6d122bd148f5
CVE: CVE-2025-40224
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

hwmon: (cgbc-hwmon) Add missing NULL check after devm_kzalloc()

The driver allocates memory for sensor data using devm_kzalloc(), but
did not check if the allocation succeeded. In case of memory allocation
failure, dereferencing the NULL pointer would lead to a kernel crash.

Add a NULL pointer check and return -ENOMEM to handle allocation failure
properly.
References: https://git.kernel.org/stable/c/240b82b86a091c1aa49d951d[PII_REDACTED]a081a0; https://git.kernel.org/stable/c/a09a5aa8bf258ddc99a22c30f17fe304b96b5350
CVE: CVE-2025-40225
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/panthor: Fix kernel panic on partial unmap of a GPU VA region

This commit address a kernel panic issue that can happen if Userspace
tries to partially unmap a GPU virtual region (aka drm_gpuva).
The VM_BIND interface allows partial unmapping of a BO.

Panthor driver pre-allocates memory for the new drm_gpuva structures
that would be needed for the map/unmap operation, done using drm_gpuvm
layer. It expected that only one new drm_gpuva would be needed on umap
but a partial unmap can require 2 new drm_gpuva and that's why it
ended up doing a NULL pointer dereference causing a kernel panic.

Following dump was seen when partial unmap was exercised.
 Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
 Mem abort info:
   ESR = 0x[PII_REDACTED]000046
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x06: level 2 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000
   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=000000088a863000
 [[PII_REDACTED]00078] pgd=080000088a842003, p4d=080000088a842003, pud=[PII_REDACTED]bf5003, pmd=[PII_REDACTED]
 Internal error: Oops: [PII_REDACTED] [#1] PREEMPT SMP
 <snip>
 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]
 lr : panthor_gpuva_sm_step_remap+0x6c/0x330 [panthor]
 sp : ffff800085d43970
 x29: ffff800085d43970 x28: ffff00080363e440 x27: ffff0008090c6000
 x26: [PII_REDACTED] x25: ffff800085d439f8 x24: ffff00080d402000
 x23: ffff800085d43b60 x22: ffff800085d439e0 x21: ffff00080abdb180
 x20: [PII_REDACTED] x19: [PII_REDACTED] x18: [PII_REDACTED]
 x17: 6e656c202c303030 x16: [PII_REDACTED] x15: 393d61766f69202c
 x14: 312d3d7361203a70 x13: 303030323d6e656c x12: ffff80008324bf58
 x11: [PII_REDACTED] x10: [PII_REDACTED] x9 : ffff8000801a6a9c
 x8 : ffff00080360b300 x7 : [PII_REDACTED] x6 : 000000088aa35fc7
 x5 : fff[PII_REDACTED]00 x4 : ffff8000842ddd30 x3 : [PII_REDACTED]
 x2 : [PII_REDACTED] x1 : [PII_REDACTED] x0 : [PII_REDACTED]
 Call trace:
  panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]
  op_remap_cb.isra.22+0x50/0x80
  __drm_gpuvm_sm_unmap+0x10c/0x1c8
  drm_gpuvm_sm_unmap+0x40/0x60
  panthor_vm_exec_op+0xb4/0x3d0 [panthor]
  panthor_vm_bind_exec_sync_op+0x154/0x278 [panthor]
  panthor_ioctl_vm_bind+0x160/0x4a0 [panthor]
  drm_ioctl_kernel+0xbc/0x138
  drm_ioctl+0x240/0x500
  __arm64_sys_ioctl+0xb0/0xf8
  invoke_syscall+0x4c/0x110
  el0_svc_common.constprop.1+0x98/0xf8
  do_el0_svc+0x24/0x38
  el0_svc+0x40/0xf8
  el0t_64_sync_handler+0xa0/0xc8
  el0t_64_sync+0x174/0x178
References: https://git.kernel.org/stable/c/4eabd0d8791eaf9a7b114ccbf56eb488aefe7b1f; https://git.kernel.org/stable/c/e9c19d19dd7e08db89cead5b0337c18590dc6645; https://git.kernel.org/stable/c/efe6dced3512066ebee2cf7c4c38d1c99625814e
CVE: CVE-2025-40226
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scmi: Account for failed debug initialization

When the SCMI debug subsystem fails to initialize, the related debug root
will be missing, and the underlying descriptor will be NULL.

Handle this fault condition in the SCMI debug helpers that maintain
metrics counters.
References: https://git.kernel.org/stable/c/2290ab43b9d8eafb8046387f10a8dfa2b030ba46; https://git.kernel.org/stable/c/554c9d5c6c695aedaecfb4365c[PII_REDACTED]7b0; https://git.kernel.org/stable/c/d719ce9f286c439795cd2beee4c91f12b84bc5a0
CVE: CVE-2025-40227
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/damon/sysfs: dealloc commit test ctx always

The damon_ctx for testing online DAMON parameters commit inputs is
deallocated only when the test fails.  This means memory is leaked for
every successful online DAMON parameters commit.  Fix the leak by always
deallocating it.
References: https://git.kernel.org/stable/c/139e7a572af0b45f558b5e502121a768dc328ba8; https://git.kernel.org/stable/c/ba236520ae53418859f4b7c7de3c71478d3c0b5a
CVE: CVE-2025-40228
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/damon/sysfs: catch commit test ctx alloc failure

Patch series "mm/damon/sysfs: fix commit test damon_ctx [de]allocation".

DAMON sysfs interface dynamically allocates and uses a damon_ctx object
for testing if given inputs for online DAMON parameters update is valid.
The object is being used without an allocation failure check, and leaked
when the test succeeds.  Fix the two bugs.


This patch (of 2):

The damon_ctx for testing online DAMON parameters commit inputs is used
without its allocation failure check.  This could result in an invalid
memory access.  Fix it by directly returning an error when the allocation
failed.
References: https://git.kernel.org/stable/c/5b3609d9b9650bdea0bfdf643e0ce57e1aed67fc; https://git.kernel.org/stable/c/f0c5118ebb0eb7e4fd6f0d2ace3315ca141b317f
CVE: CVE-2025-40229
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme

Currently, damon_destroy_scheme() only cleans up the filter list but
leaves ops_filter untouched, which could lead to memory leaks when a
scheme is destroyed.

This patch ensures both filter and ops_filter are properly freed in
damon_destroy_scheme(), preventing potential memory leaks.
References: https://git.kernel.org/stable/c/[PII_REDACTED]be845a5c4ed5fb7d3db25aa4bd04a3; https://git.kernel.org/stable/c/ff8dcf621a4172f4a6d42cbbb25d21659d3ac300
CVE: CVE-2025-40231
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

vsock: fix lock inversion in vsock_assign_transport()

Syzbot reported a potential lock inversion deadlock between
vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.

The issue was introduced by commit 687aa0c5581b ("vsock: Fix
transport_* TOCTOU") which added vsock_register_mutex locking in
vsock_assign_transport() around the transport->release() call, that can
call vsock_linger(). vsock_assign_transport() can be called with sk_lock
held. vsock_linger() calls sk_wait_event() that temporarily releases and
re-acquires sk_lock. During this window, if another thread hold
vsock_register_mutex while trying to acquire sk_lock, a circular
dependency is created.

Fix this by releasing vsock_register_mutex before calling
transport->release() and vsock_deassign_transport(). This is safe
because we don't need to hold vsock_register_mutex while releasing the
old transport, and we ensure the new transport won't disappear by
obtaining a module reference first via try_module_get().
References: https://git.kernel.org/stable/c/09bba278ccde25a14b6e5088a9e65a8717d0cccf; https://git.kernel.org/stable/c/251caee792a21eb0b781aab91362b422c945e162; https://git.kernel.org/stable/c/42ed0784d11adebf748711e503af0eb9f1e6d81d
CVE: CVE-2025-40232
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

rv: Fully convert enabled_monitors to use list_head as iterator

The callbacks in enabled_monitors_seq_ops are inconsistent. Some treat the
iterator as struct rv_monitor *, while others treat the iterator as struct
list_head *.

This causes a wrong type cast and crashes the system as reported by Nathan.

Convert everything to use struct list_head * as iterator. This also makes
enabled_monitors consistent with available_monitors.
References: https://git.kernel.org/stable/c/103541e6a5854b08a25e4caa61e990af1009a52e; https://git.kernel.org/stable/c/8948a0338d33c4a7ef1e0c439a3ad1d5fe9355ae
CVE: CVE-2025-40233
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: clear extent cache after moving/defragmenting extents

The extent map cache can become stale when extents are moved or
defragmented, causing subsequent operations to see outdated extent flags. 
This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().

The problem occurs when:
1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED
2. ioctl(FITRIM) triggers ocfs2_move_extents()
3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)
4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()
   which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)
5. The extent map cache is not invalidated after the move
6. Later write() operations read stale cached flags (0x2) but disk has
   updated flags (0x0), causing a mismatch
7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers

Fix by clearing the extent map cache after each extent move/defrag
operation in __ocfs2_move_extents_range().  This ensures subsequent
operations read fresh extent data from disk.
References: https://git.kernel.org/stable/c/78a63493f8e352296dbc7cb7b3f4973105e8679e; https://git.kernel.org/stable/c/93166bc53c0e[PII_REDACTED]a4121daea34b4fecd5; https://git.kernel.org/stable/c/93b1ab422f1966b71561158e1aedce4ec100f357
CVE: CVE-2025-40234
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/x86: alienware-wmi-wmax: Fix NULL pointer dereference in sleep handlers

Devices without the AWCC interface don't initialize `awcc`. Add a check
before dereferencing it in sleep handlers.
References: https://git.kernel.org/stable/c/24c3812c9e817d19e4842d[PII_REDACTED]de1ddcb4; https://git.kernel.org/stable/c/a49c4d48c3b60926e6a8cec217bf95aa65388ecc
CVE: CVE-2025-40235
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots()

If fs_info->super_copy or fs_info->super_for_commit allocated failed in
btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info().
Otherwise btrfs_check_leaked_roots() would access NULL pointer because
fs_info->allocated_roots had not been initialised.

syzkaller reported the following information:
  ------------[ cut here ]------------
  BUG: unable to handle page fault for address: fffffffffffffbb0
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0
  Oops: Oops: 0000 [#1] SMP KASAN PTI
  CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...)
  RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline]
  RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline]
  RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline]
  RIP: 0010:refcount_read include/linux/refcount.h:170 [inline]
  RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230
  [...]
  Call Trace:
   <TASK>
   btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280
   btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029
   btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097
   vfs_get_tree+0x98/0x320 fs/super.c:1759
   do_new_mount+0x357/0x660 fs/namespace.c:3899
   path_mount+0x716/0x19c0 fs/namespace.c:4226
   do_mount fs/namespace.c:4239 [inline]
   __do_sys_mount fs/namespace.c:4450 [inline]
   __se_sys_mount fs/namespace.c:4427 [inline]
   __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f032eaffa8d
  [...]
References: https://git.kernel.org/stable/c/0c2b2d4d053e9840e6da6ed581befa20309f281a; https://git.kernel.org/stable/c/17679ac6df6c4830ba711835aa8cf961be36cfa1; https://git.kernel.org/stable/c/b1c2b4e6ffd307720ab6ce42f6749b0c02ba0a73
CVE: CVE-2025-40236
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-net: zero unused hash fields

When GSO tunnel is negotiated virtio_net_hdr_tnl_from_skb() tries to
initialize the tunnel metadata but forget to zero unused rxhash
fields. This may leak information to another side. Fixing this by
zeroing the unused hash fields.
References: https://git.kernel.org/stable/c/b2284768c6b32aa224ca7d0ef0741beb434f03aa; https://git.kernel.org/stable/c/b625d231c66a6041e98817ffc944bf6e4c45b2e3
CVE: CVE-2025-40237
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/notify: call exportfs_encode_fid with s_umount

Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while
the overlayfs is being unmounted, can lead to dereferencing NULL ptr.

This issue was found by syzkaller.

Race Condition Diagram:

Thread 1                           Thread 2
--------                           --------

generic_shutdown_super()
 shrink_dcache_for_umount
  sb->s_root = NULL

                    |
                    |             vfs_read()
                    |              inotify_fdinfo()
                    |               * inode get from mark *
                    |               show_mark_fhandle(m, inode)
                    |                exportfs_encode_fid(inode, ..)
                    |                 ovl_encode_fh(inode, ..)
                    |                  ovl_check_encode_origin(inode)
                    |                   * deref i_sb->s_root *
                    |
                    |
                    v
 fsnotify_sb_delete(sb)

Which then leads to:

[   32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc[PII_REDACTED]: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI
[   32.134438] KASAN: null-ptr-deref in range [0x[PII_REDACTED]000030-0x[PII_REDACTED]000037]
[   32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)

<snip registers, unreliable trace>

[   32.143353] Call Trace:
[   32.143732]  ovl_encode_fh+0xd5/0x170
[   32.144031]  exportfs_encode_inode_fh+0x12f/0x300
[   32.144425]  show_mark_fhandle+0xbe/0x1f0
[   32.145805]  inotify_fdinfo+0x226/0x2d0
[   32.146442]  inotify_show_fdinfo+0x1c5/0x350
[   32.147168]  seq_show+0x530/0x6f0
[   32.147449]  seq_read_iter+0x503/0x12a0
[   32.148419]  seq_read+0x31f/0x410
[   32.150714]  vfs_read+0x1f0/0x9e0
[   32.152297]  ksys_read+0x125/0x240

IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set
to NULL in the unmount path.

Fix it by protecting calling exportfs_encode_fid() from
show_mark_fhandle() with s_umount lock.

This form of fix was suggested by Amir in [1].

[1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/
References: https://git.kernel.org/stable/c/3f307a9f7a7a2822e38ac451b73e2244e7279496; https://git.kernel.org/stable/c/950b604384fd75d62e860bec7135b2b62eb4d508; https://git.kernel.org/stable/c/a7c4bb43bfdc2b9f06ee9d036028ed13a83df42a
CVE: CVE-2025-40239
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: phy: micrel: always set shared->phydev for LAN8814

Currently, during the LAN8814 PTP probe shared->phydev is only set if PTP
clock gets actually set, otherwise the function will return before setting
it.

This is an issue as shared->phydev is unconditionally being used when IRQ
is being handled, especially in lan8814_gpio_process_cap and since it was
not set it will cause a NULL pointer exception and crash the kernel.

So, simply always set shared->phydev to avoid the NULL pointer exception.
References: https://git.kernel.org/stable/c/399d10934740ae8cdaa4e3245f7c5f6c332da844; https://git.kernel.org/stable/c/b093b06826b836c[PII_REDACTED]db080c190c04715; https://git.kernel.org/stable/c/da1ef8e9eb5d4a12bec32d11636e521e7d529b9e
CVE: CVE-2025-40240
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: avoid NULL dereference when chunk data buffer is missing

chunk->skb pointer is dereferenced in the if-block where it's supposed
to be NULL only.

chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list
instead and do it just before replacing chunk->skb. We're sure that
otherwise chunk->skb is non-NULL because of outer if() condition.
References: https://git.kernel.org/stable/c/03e80a4b04ef1fb2c61dd63216ab8d3a5dcb196f; https://git.kernel.org/stable/c/08165c[PII_REDACTED]63130919f2aae59b5822f016; https://git.kernel.org/stable/c/441f0647f7673e0e64d4910ef61a5fb8f16bfb82
CVE: CVE-2025-40241
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: fix crafted invalid cases for encoded extents

Robert recently reported two corrupted images that can cause system
crashes, which are related to the new encoded extents introduced
in Linux 6.15:

  - The first one [1] has plen != 0 (e.g. plen == 0x2000000) but
    (plen & Z_EROFS_EXTENT_PLEN_MASK) == 0. It is used to represent
    special extents such as sparse extents (!EROFS_MAP_MAPPED), but
    previously only plen == 0 was handled;

  - The second one [2] has pa 0xffffffffffdcffed and plen 0xb4000,
    then "cur [0xfffffffffffff000] += bvec.bv_len [0x1000]" in
    "} while ((cur += bvec.bv_len) < end);" wraps around, causing an
    out-of-bound access of pcl->compressed_bvecs[] in
    z_erofs_submit_queue().  EROFS only supports 48-bit physical block
    addresses (up to 1EiB for 4k blocks), so add a sanity check to
    enforce this.
References: https://git.kernel.org/stable/c/00d8fe0b72f4ca0a983abced36aad2160038c421; https://git.kernel.org/stable/c/a429b76114aaca3ef1aff4cd469dcf025431bd11
CVE: CVE-2025-40242
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix unlikely race in gdlm_put_lock

In gdlm_put_lock(), there is a small window of time in which the
DFL_UNMOUNT flag has been set but the lockspace hasn't been released,
yet.  In that window, dlm may still call gdlm_ast() and gdlm_bast().
To prevent it from dereferencing freed glock objects, only free the
glock if the lockspace has actually been released.
References: https://git.kernel.org/stable/c/279bde3bbb0ac0bad5c729dfa85983d75a5d7641; https://git.kernel.org/stable/c/28c4d9bc0708956c1a736a9e49fee71b65deee81; https://git.kernel.org/stable/c/4913592a3358f6ec366b8346b733d5e2360b08e1
CVE: CVE-2025-40245
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

nios2: ensure that memblock.current_limit is set when setting pfn limits

On nios2, with CONFIG_FLATMEM set, the kernel relies on
memblock_get_current_limit() to determine the limits of mem_map, in
particular for max_low_pfn.
Unfortunately, memblock.current_limit is only default initialized to
MEMBLOCK_ALLOC_ANYWHERE at this point of the bootup, potentially leading
to situations where max_low_pfn can erroneously exceed the value of
max_pfn and, thus, the valid range of available DRAM.

This can in turn cause kernel-level paging failures, e.g.:

[   76.900000] Unable to handle kernel paging request at virtual address 20303000
[   76.900000] ea = c0080890, ra = c000462c, cause = 14
[   76.900000] Kernel panic - not syncing: Oops
[   76.900000] ---[ end Kernel panic - not syncing: Oops ]---

This patch fixes this by pre-calculating memblock.current_limit
based on the upper limits of the available memory ranges via
adjust_lowmem_bounds, a simplified version of the equivalent
implementation within the arm architecture.
References: https://git.kernel.org/stable/c/25f09699edd360b534ccae16bc276c3b52c471f3; https://git.kernel.org/stable/c/5c3e38a367822f036227dd52bac82dc4a05157e2; https://git.kernel.org/stable/c/8912814f14e298b83df072fecc1f7ed1b63b1b2c