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

pid: Add a judgment for ns null in pid_nr_ns

__task_pid_nr_ns
        ns = task_active_pid_ns(current);
        pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);
                if (pid && ns->level <= pid->level) {

Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.

For example:
	Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
	Mem abort info:
	ESR = 0x[PII_REDACTED]000007
	EC = 0x25: DABT (current EL), IL = 32 bits
	SET = 0, FnV = 0
	EA = 0, S1PTW = 0
	FSC = 0x07: level 3 translation fault
	Data abort info:
	ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
	CM = 0, WnR = 0, TnD = 0, TagAccess = 0
	GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
	user pgtable: 4k pages, 39-bit VAs, pgdp=[PII_REDACTED]5aa000
	[[PII_REDACTED]] pgd=[PII_REDACTED]5ab003, p4d=[PII_REDACTED]5ab003, pud=[PII_REDACTED]5ab003, pmd=[PII_REDACTED]5be003, pte=[PII_REDACTED]
	pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
	pc : __task_pid_nr_ns+0x74/0xd0
	lr : __task_pid_nr_ns+0x24/0xd0
	sp : ffffffc08001bd10
	x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: [PII_REDACTED]
	x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31
	x23:[PII_REDACTED]0000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0
	x20: [PII_REDACTED] x19: [PII_REDACTED] x18: [PII_REDACTED]
	x17:[PII_REDACTED]9c6ef0 x16:[PII_REDACTED]9c6ef0 x15:[PII_REDACTED]3a1adc
	x14: [PII_REDACTED] x13:[PII_REDACTED]7ef6d8 x12: 001167c391c78800
	x11: 00ffffffffffffff x10: [PII_REDACTED] x9 : [PII_REDACTED]
	x8 : ffffff80816fa3c0 x7 : [PII_REDACTED] x6 : 49534d702d535449
	x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc
	x2 : [PII_REDACTED] x1 : [PII_REDACTED] x0 : ffffff806f5693c0
	Call trace:
	__task_pid_nr_ns+0x74/0xd0
	...
	__handle_irq_event_percpu+0xd4/0x284
	handle_irq_event+0x48/0xb0
	handle_fasteoi_irq+0x160/0x2d8
	generic_handle_domain_irq+0x44/0x60
	gic_handle_irq+0x4c/0x114
	call_on_irq_stack+0x3c/0x74
	do_interrupt_handler+0x4c/0x84
	el1_interrupt+0x34/0x58
	el1h_64_irq_handler+0x18/0x24
	el1h_64_irq+0x68/0x6c
	account_kernel_stack+0x60/0x144
	exit_task_stack_account+0x1c/0x80
	do_exit+0x7e4/0xaf8
	...
	get_signal+0x7bc/0x8d8
	do_notify_resume+0x128/0x828
	el0_svc+0x6c/0x70
	el0t_64_sync_handler+0x68/0xbc
	el0t_64_sync+0x1a8/0x1ac
	Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)
	---[ end trace [PII_REDACTED] ]---
	Kernel panic - not syncing: Oops: Fatal exception in interrupt
References: https://git.kernel.org/stable/c/006568ab4c5ca2309ceb36fa553e390b4aa9c0c7; https://git.kernel.org/stable/c/09d227c59d97efda7d5cc878a4335a6b2bb224c2; https://git.kernel.org/stable/c/2076b916bf41be48799d1443df0f8fc75d12ccd0
CVE: CVE-2025-40179
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: verify orphan file size is not too big

In principle orphan file can be arbitrarily large. However orphan replay
needs to traverse it all and we also pin all its buffers in memory. Thus
filesystems with absurdly large orphan files can lead to big amounts of
memory consumed. Limit orphan file size to a sane value and also use
kvmalloc() for allocating array of block descriptor structures to avoid
large order allocations for sane but large orphan files.
References: https://git.kernel.org/stable/c/0a6ce20c156442a4ce2a404747bb0fb05d54eeb3; https://git.kernel.org/stable/c/2b9da798ff0f4d026c5f0f815047393ebe7d8859; https://git.kernel.org/stable/c/304fc34ff6fc8261138fd81f119e024ac3a129e9
CVE: CVE-2025-40180
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop

The cleanup loop was starting at the wrong array index, causing
out-of-bounds access.
Start the loop at the correct index for zero-indexed arrays to prevent
accessing memory beyond the allocated array bounds.
References: https://git.kernel.org/stable/c/0aead8197fc1a85b0a89646e418feb49a564b029; https://git.kernel.org/stable/c/ab96f08ecedd263ecaab9df8455bfb23b07fdcc2; https://git.kernel.org/stable/c/cd0cbf2713f6e027ebba867cb7409ae345a31312
CVE: CVE-2025-40182
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: skcipher - Fix reqsize handling

Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg")
introduced cra_reqsize field in crypto_alg struct to replace type
specific reqsize fields. It looks like this was introduced specifically
for ahash and acomp from the commit description as subsequent commits
add necessary changes in these alg frameworks.

However, this is being recommended for use in all crypto algs [1]
instead of setting reqsize using crypto_*_set_reqsize(). Using
cra_reqsize in skcipher algorithms, hence, causes memory
corruptions and crashes as the underlying functions in the algorithm
framework have not been updated to set the reqsize properly from
cra_reqsize. [2]

Add proper set_reqsize calls in the skcipher init function to
properly initialize reqsize for these algorithms in the framework.

[1]: https://lore.kernel.org/linux-crypto/aCL8BxpHr5OpT04k@gondor.apana.org.au/
[2]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b
References: https://git.kernel.org/stable/c/229c586b5e86979badb7cb0d38717b88a9e95ddd; https://git.kernel.org/stable/c/f041339d6b9a5a46437f0c48fc7279c92af7a513
CVE: CVE-2025-40183
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}

Cilium has a BPF egress gateway feature which forces outgoing K8s Pod
traffic to pass through dedicated egress gateways which then SNAT the
traffic in order to interact with stable IPs outside the cluster.

The traffic is directed to the gateway via vxlan tunnel in collect md
mode. A recent BPF change utilized the bpf_redirect_neigh() helper to
forward packets after the arrival and decap on vxlan, which turned out
over time that the kmalloc-256 slab usage in kernel was ever-increasing.

The issue was that vxlan allocates the metadata_dst object and attaches
it through a fake dst entry to the skb. The latter was never released
though given bpf_redirect_neigh() was merely setting the new dst entry
via skb_dst_set() without dropping an existing one first.
References: https://git.kernel.org/stable/c/057764172fcc6ee2ccb6c41351a55a9f054dc8fd; https://git.kernel.org/stable/c/23f3770e1a53e6c7a553135011f547209e141e72; https://git.kernel.org/stable/c/2e67c2037382abb56497bb9d7b7e10be04eb5598
CVE: CVE-2025-40185
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: ice_adapter: release xa entry on adapter allocation failure

When ice_adapter_new() fails, the reserved XArray entry created by
xa_insert() is not released. This causes subsequent insertions at
the same index to return -EBUSY, potentially leading to
NULL pointer dereferences.

Reorder the operations as suggested by Przemek Kitszel:
1. Check if adapter already exists (xa_load)
2. Reserve the XArray slot (xa_reserve)
3. Allocate the adapter (ice_adapter_new)
4. Store the adapter (xa_store)
References: https://git.kernel.org/stable/c/2db687f3469dbc5c59bc53d55acafd75d530b497; https://git.kernel.org/stable/c/794abb265de3e792167fe3ea0440c064c722bb84; https://git.kernel.org/stable/c/7b9269de9815fc34d93dab90bd5169bacbe78e70
CVE: CVE-2025-40186
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request().

syzbot reported the splat below in tcp_conn_request(). [0]

If a listener is close()d while a TFO socket is being processed in
tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->sk
and calls inet_child_forget(), which calls tcp_disconnect() for the
TFO socket.

After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(),
where reqsk_put() is called due to !reqsk->sk.

Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the
last req->rsk_refcnt and frees reqsk, and __reqsk_free() at the
drop_and_free label causes the refcount underflow for the listener
and double-free of the reqsk.

Let's remove reqsk_fastopen_remove() in tcp_conn_request().

Note that other callers make sure tp->fastopen_rsk is not NULL.

[0]:
refcount_t: underflow; use-after-free.
WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28)
Modules linked in:
CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
RIP: 0010:refcount_warn_saturate (lib/refcount.c:28)
Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6
RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246
RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900
RDX: [PII_REDACTED] RSI: 00000000ffff7fff RDI: ffffffffac78a280
RBP: 000000009d781b60 R08:[PII_REDACTED]007fff R09: ffffffffac6ca280
R10:[PII_REDACTED]017ffd R11: [PII_REDACTED] R12: ffff9f65c7b4f100
R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8
FS:  00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: [PII_REDACTED] CR3: 000000000dbbe006 CR4:[PII_REDACTED]372ef0
Call Trace:
 <IRQ>
 tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301)
 tcp_rcv_state_process (net/ipv4/tcp_input.c:6708)
 tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670)
 tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906)
 ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438)
 ip6_input (net/ipv6/ip6_input.c:500)
 ipv6_rcv (net/ipv6/ip6_input.c:311)
 __netif_receive_skb (net/core/dev.c:6104)
 process_backlog (net/core/dev.c:6456)
 __napi_poll (net/core/dev.c:7506)
 net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696)
 handle_softirqs (kernel/softirq.c:579)
 do_softirq (kernel/softirq.c:480)
 </IRQ>
References: https://git.kernel.org/stable/c/2e7cbbbe3d61c63606994b7ff73c72537afe2e1c; https://git.kernel.org/stable/c/422c1c173c39bbbae1e0eaaf8aefe40b2596233b; https://git.kernel.org/stable/c/643a94b0cf767325e953591c212be2eb826b9d7f
CVE: CVE-2025-40187
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()

If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0
and sctp_ulpevent_make_authkey() returns 0, then the variable
ai_ev remains zero and the zero will be dereferenced
in the sctp_ulpevent_free() function.
References: https://git.kernel.org/stable/c/025419f4e216a3ae0d0cec622262e98e8078c447; https://git.kernel.org/stable/c/1014b83778c8677f1d7a57c26dc728baa801ac62; https://git.kernel.org/stable/c/2f3119686ef50319490ccaec81a575973da98815
CVE: CVE-2025-40188
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

pwm: berlin: Fix wrong register in suspend/resume

The 'enable' register should be BERLIN_PWM_EN rather than
BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there
will be cpu exception then kernel panic during suspend/resume.
References: https://git.kernel.org/stable/c/3a4b9d027e4061766f618292df91760ea64a1fcc; https://git.kernel.org/stable/c/5419c86ea134b8a5b8126f55fa5bc1ad7b3ca444; https://git.kernel.org/stable/c/6cef9e4425143b19742044c8a675335821fa1994
CVE: CVE-2025-40189
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net: usb: lan78xx: Fix lost EEPROM read timeout error(-ETIMEDOUT) in lan78xx_read_raw_eeprom

Syzbot reported read of uninitialized variable BUG with following call stack.

lan78xx 8-1:1.0 (unnamed net_device) (uninitialized): EEPROM read operation timeout
=====================================================
BUG: KMSAN: uninit-value in lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline]
BUG: KMSAN: uninit-value in lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]
BUG: KMSAN: uninit-value in lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241
 lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline]
 lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]
 lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241
 lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766
 lan78xx_probe+0x225c/0x3310 drivers/net/usb/lan78xx.c:4707

Local variable sig.i.i created at:
 lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1092 [inline]
 lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]
 lan78xx_reset+0x77e/0x2cd0 drivers/net/usb/lan78xx.c:3241
 lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766

The function lan78xx_read_raw_eeprom failed to properly propagate EEPROM
read timeout errors (-ETIMEDOUT). In the fallthrough path, it first
attempted to restore the pin configuration for LED outputs and then
returned only the status of that restore operation, discarding the
original timeout error.

As a result, callers could mistakenly treat the data buffer as valid
even though the EEPROM read had actually timed out with no data or partial
data.

To fix this, handle errors in restoring the LED pin configuration separately.
If the restore succeeds, return any prior EEPROM timeout error correctly
to the caller.
References: https://git.kernel.org/stable/c/49bdb63ff64469a6de8ea901aef123c75be9bbe7; https://git.kernel.org/stable/c/a72a7c4f675080a324d4c2167bd2314d968279f1
CVE: CVE-2025-40190
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: guard against EA inode refcount underflow in xattr update

syzkaller found a path where ext4_xattr_inode_update_ref() reads an EA
inode refcount that is already <= 0 and then applies ref_change (often
-1). That lets the refcount underflow and we proceed with a bogus value,
triggering errors like:

  EXT4-fs error: EA inode <n> ref underflow: ref_count=-1 ref_change=-1
  EXT4-fs warning: ea_inode dec ref err=-117

Make the invariant explicit: if the current refcount is non-positive,
treat this as on-disk corruption, emit ext4_error_inode(), and fail the
operation with -EFSCORRUPTED instead of updating the refcount. Delete the
WARN_ONCE() as negative refcounts are now impossible; keep error reporting
in ext4_error_inode().

This prevents the underflow and the follow-on orphan/cleanup churn.
References: https://git.kernel.org/stable/c/1cfb3e4ddbdc8e02e637b8852540bd4718bf4814; https://git.kernel.org/stable/c/3d[PII_REDACTED]f4484bfed403c947a114bb583631; https://git.kernel.org/stable/c/440b003f449a4ff2a00b08c8eab9ba5cd28f3943
CVE: CVE-2025-40191
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix kfd process ref leaking when userptr unmapping

kfd_lookup_process_by_pid hold the kfd process reference to ensure it
doesn't get destroyed while sending the segfault event to user space.

Calling kfd_lookup_process_by_pid as function parameter leaks the kfd
process refcount and miss the NULL pointer check if app process is
already destroyed.
References: https://git.kernel.org/stable/c/58e6fc2fb94f0f409447e5d46cf6a417b6397fbc; https://git.kernel.org/stable/c/60f6112fc9b3ba0eae519f10702c0c13bab45742
CVE: CVE-2025-40192
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

Revert "ipmi: fix msg stack when IPMI is disconnected"

This reverts commit c608966f3f9c2dca596967501d00753282b395fc.

This patch has a subtle bug that can cause the IPMI driver to go into an
infinite loop if the BMC misbehaves in a certain way.  Apparently
certain BMCs do misbehave this way because several reports have come in
recently about this.
References: https://git.kernel.org/stable/c/5d09ee1bec870263f4ace439402ea840503b503b; https://git.kernel.org/stable/c/8cf5c24533b8058910fcb83a25a9cf[PII_REDACTED]; https://git.kernel.org/stable/c/b9cc7155e65f6feca51bfedd543b9bd300e2be2b
CVE: CVE-2025-40193
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

xtensa: simdisk: add input size check in proc_write_simdisk

A malicious user could pass an arbitrarily bad value
to memdup_user_nul(), potentially causing kernel crash.

This follows the same pattern as commit ee76746387f6
("netdevsim: prevent bad user input in nsim_dev_health_break_write()")
References: https://git.kernel.org/stable/c/151bd88859474cdaccc1e4c8b21fbf72dbba2ab4; https://git.kernel.org/stable/c/5d5f08fd0cd970184376bee07d59f635c8403f63; https://git.kernel.org/stable/c/a0c2c36d864ef3676b05cfd8c58b72ee3214cb1a
CVE: CVE-2025-40194
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()

The cpufreq_cpu_put() call in update_qos_request() takes place too early
because the latter subsequently calls freq_qos_update_request() that
indirectly accesses the policy object in question through the QoS request
object passed to it.

Fortunately, update_qos_request() is called under intel_pstate_driver_lock,
so this issue does not matter for changing the intel_pstate operation
mode, but it theoretically can cause a crash to occur on CPU device hot
removal (which currently can only happen in virt, but it is formally
supported nevertheless).

Address this issue by modifying update_qos_request() to drop the
reference to the policy later.
References: https://git.kernel.org/stable/c/0a58d3e77b22b087a57831c87cafd360e144a5bd; https://git.kernel.org/stable/c/15ac9579ebdaf22a37d7f60b3a8efc1029732ef9; https://git.kernel.org/stable/c/57e4a6aadf12578b96a038373cffd54b3a58b092
CVE: CVE-2025-40195
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

mount: handle NULL values in mnt_ns_release()

When calling in listmount() mnt_ns_release() may be passed a NULL
pointer. Handle that case gracefully.
References: https://git.kernel.org/stable/c/2d68f8a7379d9c61005e982600c61948d4d019bd; https://git.kernel.org/stable/c/6c7ca6a02f8f9549a438a08a23c6327580ecf3d6; https://git.kernel.org/stable/c/99ae3e70a293834d0274c46a37120c71a24a4995
CVE: CVE-2025-40196
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: quota: create dedicated workqueue for quota_release_work

There is a kernel panic due to WARN_ONCE when panic_on_warn is set.

This issue occurs when writeback is triggered due to sync call for an
opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance
is needed at sync path, flush for quota_release_work is triggered.
By default quota_release_work is queued to "events_unbound" queue which
does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback"
workqueue tries to flush quota_release_work causing kernel panic due to
MEM_RECLAIM flag mismatch errors.

This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag
for work quota_release_work.

------------[ cut here ]------------
WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148
Call trace:
 check_flush_dependency+0x13c/0x148
 __flush_work+0xd0/0x398
 flush_delayed_work+0x44/0x5c
 dquot_writeback_dquots+0x54/0x318
 f2fs_do_quota_sync+0xb8/0x1a8
 f2fs_write_checkpoint+0x3cc/0x99c
 f2fs_gc+0x190/0x750
 f2fs_balance_fs+0x110/0x168
 f2fs_write_single_data_page+0x474/0x7dc
 f2fs_write_data_pages+0x7d0/0xd0c
 do_writepages+0xe0/0x2f4
 __writeback_single_inode+0x44/0x4ac
 writeback_sb_inodes+0x30c/0x538
 wb_writeback+0xf4/0x440
 wb_workfn+0x128/0x5d4
 process_scheduled_works+0x1c4/0x45c
 worker_thread+0x32c/0x3e8
 kthread+0x11c/0x1b0
 ret_from_fork+0x10/0x20
Kernel panic - not syncing: kernel: panic_on_warn set ...
References: https://git.kernel.org/stable/c/72b7ceca857f38a8ca7c5629feffc[PII_REDACTED]4; https://git.kernel.org/stable/c/8a09a62f0c8c6123c2f1864ed6d5f9eb144afaf0; https://git.kernel.org/stable/c/f12039df1515d5daf7d92e586ece5cefeb39561b
CVE: CVE-2025-40197
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mc: Clear minor number before put device

The device minor should not be cleared after the device is released.
References: https://git.kernel.org/stable/c/5d327391f9fafeb0938be4fc538dd0bd54a0b2ef; https://git.kernel.org/stable/c/64dbc6f50ce92b7da203b1bcdd96a370bbc9b74d; https://git.kernel.org/stable/c/7bd4e5367d0940ccec4d7546bb6bd019ab2c71aa
CVE: CVE-2025-40198
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()

Unlike other strings in the ext4 superblock, we rely on tune2fs to
make sure s_mount_opts is NUL terminated.  Harden
parse_apply_sb_mount_options() by treating s_mount_opts as a potential
__nonstring.
References: https://git.kernel.org/stable/c/01829af7656b56d83682b3491265d583d502e502; https://git.kernel.org/stable/c/2a0cf438320cdb783e[PII_REDACTED]c0ef0d83e934; https://git.kernel.org/stable/c/7bf46ff83a0ef11836e38ebd72cdc[PII_REDACTED]d
CVE: CVE-2025-40199
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

page_pool: Fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches

Helge reported that the introduction of PP_MAGIC_MASK let to crashes on
boot on his 32-bit parisc machine. The cause of this is the mask is set
too wide, so the page_pool_page_is_pp() incurs false positives which
crashes the machine.

Just disabling the check in page_pool_is_pp() will lead to the page_pool
code itself malfunctioning; so instead of doing this, this patch changes
the define for PP_DMA_INDEX_BITS to avoid mistaking arbitrary kernel
pointers for page_pool-tagged pages.

The fix relies on the kernel pointers that alias with the pp_magic field
always being above PAGE_OFFSET. With this assumption, we can use the
lowest bit of the value of PAGE_OFFSET as the upper bound of the
PP_DMA_INDEX_MASK, which should avoid the false positives.

Because we cannot rely on PAGE_OFFSET always being a compile-time
constant, nor on it always being >0, we fall back to disabling the
dma_index storage when there are not enough bits available. This leaves
us in the situation we were in before the patch in the Fixes tag, but
only on a subset of architecture configurations. This seems to be the
best we can do until the transition to page types in complete for
page_pool pages.

v2:
- Make sure there's at least 8 bits available and that the PAGE_OFFSET
  bit calculation doesn't wrap
References: https://git.kernel.org/stable/c/15b8a5b4cdc16e9a8bb2a548e12a0fd92997605a; https://git.kernel.org/stable/c/95920c2ed02bde551ab654e9749c2ca7bc3100e0; https://git.kernel.org/stable/c/f62934cea32c8f7b11b747975d69bf5afe4264cf
CVE: CVE-2025-40200
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

Squashfs: reject negative file sizes in squashfs_read_inode()

Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs.

This warning is ultimately caused because the underlying Squashfs file
system returns a file with a negative file size.

This commit checks for a negative file size and returns EINVAL.

[phillip@squashfs.org.uk: only need to check 64 bit quantity]
References: https://git.kernel.org/stable/c/2871c74caa3f4f05b429e6bfefebac62dbf1b408; https://git.kernel.org/stable/c/54170057a5fadd24a37b70de41e61d39284d9bd7; https://git.kernel.org/stable/c/8118f[PII_REDACTED]9443d09c207e654adcb2f9321