CVE-2025-38320

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

7.1 HighFix available

What does this mean?

: 7.1v3.1, from NVD
: 0.21%11th percentile
Fixed in: 6.6.96.1-1kernel
Published: July 10, 2025
Modified: November 10, 2026
Weakness: CWE-125
Also known as: AZL-64916BELL-CVE-2025-38320CLSA-2025-1757963029CLSA-2026-1771081379CLSA-2026-1771239384DEBIAN-CVE-2025-38320DLA-4327-1DLA-4328-1
Show 47 moreShow less
DSA-5973-1EUVD-2025-20926GHSA-784p-42hr-j7xpMGASA-2025-0218MGASA-2025-0219OESA-2025-1869OESA-2025-1870OESA-2025-1871OESA-2025-1872OESA-2025-1873OESA-2025-1874ROOT-OS-DEBIAN-11-CVE-2025-38320ROOT-OS-DEBIAN-12-CVE-2025-38320ROOT-OS-UBUNTU-2204-CVE-2025-38320ROOT-OS-UBUNTU-2404-CVE-2025-38320UBUNTU-CVE-2025-38320USN-7774-1USN-7774-2USN-7774-3USN-7774-4USN-7774-5USN-7775-1USN-7775-2USN-7775-3USN-7776-1USN-7833-1USN-7833-2USN-7833-3USN-7833-4USN-7834-1USN-7856-1USN-8028-1USN-8028-2USN-8028-3USN-8028-4USN-8028-5USN-8028-6USN-8028-7USN-8028-8USN-8031-1USN-8031-2USN-8031-3USN-8052-1USN-8052-2USN-8074-1USN-8074-2USN-8126-1

In the Linux kernel, the following vulnerability has been resolved:

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().

Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 97.287815] Call trace: [ 97.288279] dump_backtrace+0xa0/0x128 [ 97.288946] show_stack+0x20/0x38 [ 97.289551] dump_stack_lvl+0x78/0xc8 [ 97.290203] print_address_description.constprop.0+0x84/0x3c8 [ 97.291159] print_report+0xb0/0x280 [ 97.291792] kasan_report+0x84/0xd0 [ 97.292421] __asan_load8+0x9c/0xc0 [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.293835] process_fetch_insn+0x770/0xa30 [ 97.294562] kprobe_trace_func+0x254/0x3b0 [ 97.295271] kprobe_dispatcher+0x98/0xe0 [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210 [ 97.296774] call_break_hook+0xc4/0x100 [ 97.297451] brk_handler+0x24/0x78 [ 97.298073] do_debug_exception+0xac/0x178 [ 97.298785] el1_dbg+0x70/0x90 [ 97.299344] el1h_64_sync_handler+0xcc/0xe8 [ 97.300066] el1h_64_sync+0x78/0x80 [ 97.300699] kernel_clone+0x0/0x500 [ 97.301331] __arm64_sys_clone+0x70/0x90 [ 97.302084] invoke_syscall+0x68/0x198 [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150 [ 97.303569] do_el0_svc+0x38/0x50 [ 97.304164] el0_svc+0x44/0x1d8 [ 97.304749] el0t_64_sync_handler+0x100/0x130 [ 97.305500] el0t_64_sync+0x188/0x190 [ 97.306151] [ 97.306475] The buggy address belongs to stack of task 1.sh/2550 [ 97.307461] and is located at offset 0 in frame: [ 97.308257] __se_sys_clone+0x0/0x138 [ 97.308910] [ 97.309241] This frame has 1 object: [ 97.309873] [48, 184) 'args' [ 97.309876] [ 97.310749] The buggy address belongs to the virtual mapping at [ 97.310749] [ffff800089270000, ffff800089279000) created by: [ 97.310749] dup_task_struct+0xc0/0x2e8 [ 97.313347] [ 97.313674] The buggy address belongs to the physical page: [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff) [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000 [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 97.319445] page dumped because: kasan: bad access detected [ 97.320371] [ 97.320694] Memory state around the buggy address: [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00 [ 97.325023] ^ [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before:

commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")

As described in that commit, regs_get_kernel_stack_nth() has confirmed that addr is on the stack, so reading the value at *addr should be allowed. Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case.

[will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]

Attack profile

How easy it is to exploit

Attack vector: Local
Complexity: Low
Privileges needed: Low
User interaction: None

What an attacker can affect

Confidentiality: High
Integrity: None
Availability: High

Exploit likelihood

0.21%Up 0.2 points since Jul 10, 2025

What each source reports

NVD Score used 7.1

In the Linux kernel, the following vulnerability has been resolved:

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().

This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before:

commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")

[will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]

Record: CVE-2025-38320
CVSS 3.1: 7.1 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Weakness: CWE-125
Updated: 2026-11-05

CVE List No score

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

In the Linux kernel, the following vulnerability has been resolved:

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().

This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before:

commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")

[will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]

Record: CVE-2025-38320
Updated: 2026-11-05

EUVDEUVD-2025-20926 No score

In the Linux kernel, the following vulnerability has been resolved:

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().

This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before:

commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")

[will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]

Record: EUVD-2025-20926
Updated: 2026-11-05

GitHub AdvisoriesGHSA-784p-42hr-j7xp 7.1

In the Linux kernel, the following vulnerability has been resolved: arm64/ptrace: Fix stack-out...

In the Linux kernel, the following vulnerability has been resolved:

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().

This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before:

commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")

[will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]

Record: GHSA-784p-42hr-j7xp
CVSS 3.1: 7.1 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Weakness: CWE-125
Updated: 2026-11-02

OSVBELL-CVE-2025-38320 7.1

Record: BELL-CVE-2025-38320
CVSS 3.1: 7.1 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Updated: 2026-11-02

OSVDEBIAN-CVE-2025-38320 7.1

In the Linux kernel, the following vulnerability has been resolved: arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth(). Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 97.287815] Call trace: [ 97.288279] dump_backtrace+0xa0/0x128 [ 97.288946] show_stack+0x20/0x38 [ 97.289551] dump_stack_lvl+0x78/0xc8 [ 97.290203] print_address_description.constprop.0+0x84/0x3c8 [ 97.291159] print_report+0xb0/0x280 [ 97.291792] kasan_report+0x84/0xd0 [ 97.292421] __asan_load8+0x9c/0xc0 [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.293835] process_fetch_insn+0x770/0xa30 [ 97.294562] kprobe_trace_func+0x254/0x3b0 [ 97.295271] kprobe_dispatcher+0x98/0xe0 [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210 [ 97.296774] call_break_hook+0xc4/0x100 [ 97.297451] brk_handler+0x24/0x78 [ 97.298073] do_debug_exception+0xac/0x178 [ 97.298785] el1_dbg+0x70/0x90 [ 97.299344] el1h_64_sync_handler+0xcc/0xe8 [ 97.300066] el1h_64_sync+0x78/0x80 [ 97.300699] kernel_clone+0x0/0x500 [ 97.301331] __arm64_sys_clone+0x70/0x90 [ 97.302084] invoke_syscall+0x68/0x198 [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150 [ 97.303569] do_el0_svc+0x38/0x50 [ 97.304164] el0_svc+0x44/0x1d8 [ 97.304749] el0t_64_sync_handler+0x100/0x130 [ 97.305500] el0t_64_sync+0x188/0x190 [ 97.306151] [ 97.306475] The buggy address belongs to stack of task 1.sh/2550 [ 97.307461] and is located at offset 0 in frame: [ 97.308257] __se_sys_clone+0x0/0x138 [ 97.308910] [ 97.309241] This frame has 1 object: [ 97.309873] [48, 184) 'args' [ 97.309876] [ 97.310749] The buggy address belongs to the virtual mapping at [ 97.310749] [ffff800089270000, ffff800089279000) created by: [ 97.310749] dup_task_struct+0xc0/0x2e8 [ 97.313347] [ 97.313674] The buggy address belongs to the physical page: [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff) [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000 [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 97.319445] page dumped because: kasan: bad access detected [ 97.320371] [ 97.320694] Memory state around the buggy address: [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00 [ 97.325023] ^ [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before: commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()") As described in that commit, regs_get_kernel_stack_nth() has confirmed that addr is on the stack, so reading the value at *addr should be allowed. Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case. [will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]

Record: DEBIAN-CVE-2025-38320
CVSS 3.1: 7.1 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Updated: 2026-11-02

Show 45 moreShow less

OSVOESA-2025-1869 7.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

pfifo_tail_enqueue: Drop new packet when sch->limit == 0

Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return NET_XMIT_CN status code.

Weird behaviour: In case we set sch->limit == 0 and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return NET_XMIT_CN status code.

The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B.

Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is hfsc. Enqueue packet to this qdisc will trigger hfsc_enqueue.
Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger pfifo_tail_enqueue.
Qdisc_B is configured to have sch->limit == 0.
Qdisc_A is configured to route the enqueued's packet to Qdisc_B.

Enqueue packet through Qdisc_A will lead to:

hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)
Qdisc_B->q.qlen += 1
pfifo_tail_enqueue() return NET_XMIT_CN
hfsc_enqueue() check for NET_XMIT_SUCCESS and see NET_XMIT_CN => hfsc_enqueue() don't increase qlen of Qdisc_A.

The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.

Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.(CVE-2025-21702)

In the Linux kernel, the following vulnerability has been resolved:

mptcp: always handle address removal under msk socket lock

Syzkaller reported a lockdep splat in the PM control path:

WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3:…

Record: OESA-2025-1869
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2025-1870 7.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

crypto: iaa - Fix potential use after free bug

The free_device_compression_mode(iaa_device, device_mode) function frees "device_mode" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free.

The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)(CVE-2024-47732)

In the Linux kernel, the following vulnerability has been resolved:

mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()

If migration succeeded, we called folio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from the old to the new folio. This will set memcg_data of the old folio to 0.

Similarly, if migration failed, memcg_data of the dst folio is left unset.

If we call folio_putback_lru() on such folios (memcg_data == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests:

./hmm-tests

...

RUN hmm.hmm_device_private.migrate ...

[ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] <TASK> [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] …

Record: OESA-2025-1870
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2025-1871 7.0

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel, which originates from a qlen count error in sch_hfsc, which may cause inconsistent queue statistics.(CVE-2025-38000)

In the Linux kernel, the following vulnerability has been resolved:

media: cxusb: no longer judge rbuf when the write fails

syzbot reported a uninit-value in cxusb_i2c_xfer. [1]

Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf.

In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized.

[1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-38229)

A vulnerability has been found in Linux Kernel up to 6.15.2 (Operating System) and classified as critical.The CWE definition for the vulnerability is CWE-121. A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 44ebe361abb322d2afd77930fa767a99f271c4d1/147ea936fc6fa8fe0c93f0df918803a5375ca535/ee90be48edb3dac612e0b7f5332482a9e8be2696/e167414beabb1e941fe563a96becc98627d5bdf6/6d8f39875a10a194051c3eaefebc7ac06a34aaf3/c98cdf6795a36bca163ebb40411fef1687b9eb13/18e8cbbae79cb35bdce8a01c889827b9799c762e/3880cdbed1c4607e378f58fa924c5d6df900d1d3 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38285)

A vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.As an impact it is known to affect confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 64773b3ea09235168a549a195cba43bb867c4a17/67abac27d806e8f9d4226ec1528540cf73af673a/92750bfe7b0d8dbcaf578c091a65eda1c5f9ad38/01f91d415a8375d85e0c7d3615cd4a168308bb7c/21da6d3561f373898349ca7167c9811c020da695/22f935bc86bdfbde04009f05eee191d220cd8c89/422e565b7889ebfd9c8705a3fc786642afe61fca/39dfc971e42d886e7df01371cd1bef505076d84c is able to eliminate this problem. The bugfix is ready…

Record: OESA-2025-1871
CVSS 3.1: 7.0 HighCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2025-1872 7.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT

Treat the NX bit as valid when using NPT, as KVM will set the NX bit when the NX huge page mitigation is enabled (mindblowing) and trigger the WARN that fires on reserved SPTE bits being set.

KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM: Refuse to load kvm_amd if NX support is not available") for exactly this reason, but apparently it never occurred to anyone to actually test NPT with the mitigation enabled.

------------[ cut here ]------------ spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000 WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Call Trace: <TASK> tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> ---[ end trace 0000000000000000 ]---(CVE-2022-50224)

In the Linux kernel, the following vulnerability has been resolved:

media: uvcvideo: Remove dangling pointers

When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future.

If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use.

Clean all the dangling pointers during release().

To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled.(CVE-2024-58002)

In the Linux kernel, the following vulnerability has been resolved:

ibmvnic: Don't reference skb after sending to VIOS

Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb.

It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free:

BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to…

Record: OESA-2025-1872
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2025-1873 7.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT

Treat the NX bit as valid when using NPT, as KVM will set the NX bit when the NX huge page mitigation is enabled (mindblowing) and trigger the WARN that fires on reserved SPTE bits being set.

In the Linux kernel, the following vulnerability has been resolved:

media: uvcvideo: Remove dangling pointers

When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future.

If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use.

Clean all the dangling pointers during release().

To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled.(CVE-2024-58002)

In the Linux kernel, the following vulnerability has been resolved:

ibmvnic: Don't reference skb after sending to VIOS

Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb.

It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free:

Record: OESA-2025-1873
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2025-1874 7.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

pfifo_tail_enqueue: Drop new packet when sch->limit == 0

The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B.

Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is hfsc. Enqueue packet to this qdisc will trigger hfsc_enqueue.
Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger pfifo_tail_enqueue.
Qdisc_B is configured to have sch->limit == 0.
Qdisc_A is configured to route the enqueued's packet to Qdisc_B.

Enqueue packet through Qdisc_A will lead to:

hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)
Qdisc_B->q.qlen += 1
pfifo_tail_enqueue() return NET_XMIT_CN
hfsc_enqueue() check for NET_XMIT_SUCCESS and see NET_XMIT_CN => hfsc_enqueue() don't increase qlen of Qdisc_A.

Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.(CVE-2025-21702)

In the Linux kernel, the following vulnerability has been resolved:

netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()

qdisc_tree_reduce_backlog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlen_notify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list.(CVE-2025-21703)

In the Linux kernel, the following vulnerability has been resolved:

mptcp: always handle address removal under msk socket lock

Syzkaller reported a lockdep splat in the PM control path:

Record: OESA-2025-1874
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVROOT-OS-DEBIAN-11-CVE-2025-38320 7.1

CVE-2025-38320 in linux - Patched by Root

Root has patched CVE-2025-38320 in the linux package for Root:Debian:11. Multiple fixed versions available.

Record: ROOT-OS-DEBIAN-11-CVE-2025-38320
CVSS 3.1: 7.1 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Updated: 2026-11-02

OSVROOT-OS-DEBIAN-12-CVE-2025-38320 7.1

CVE-2025-38320 in linux - Patched by Root

Root has patched CVE-2025-38320 in the linux package for Root:Debian:12. Multiple fixed versions available.

Record: ROOT-OS-DEBIAN-12-CVE-2025-38320
CVSS 3.1: 7.1 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Updated: 2026-11-02

OSVROOT-OS-UBUNTU-2204-CVE-2025-38320 7.1

CVE-2025-38320 in linux - Patched by Root

Root has patched CVE-2025-38320 in the linux package for Root:Ubuntu:22.04. Multiple fixed versions available.

Record: ROOT-OS-UBUNTU-2204-CVE-2025-38320
CVSS 3.1: 7.1 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Updated: 2026-11-06

OSVROOT-OS-UBUNTU-2404-CVE-2025-38320 7.1

CVE-2025-38320 in linux - Patched by Root

Root has patched CVE-2025-38320 in the linux package for Root:Ubuntu:24.04. Multiple fixed versions available.

Record: ROOT-OS-UBUNTU-2404-CVE-2025-38320
CVSS 3.1: 7.1 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Updated: 2026-11-06

OSVUBUNTU-CVE-2025-38320 7.1

Record: UBUNTU-CVE-2025-38320
CVSS 3.1: 7.1 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Updated: 2026-11-10

OSVAZL-64916 No score

CVE-2025-38320 affecting package kernel for versions less than 6.6.96.1-1

In the Linux kernel, the following vulnerability has been resolved:

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().

This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before:

commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")

[will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]

Record: AZL-64916
Updated: 2026-11-02

OSVCLSA-2025-1757963029 No score

kernel-uek: Fix of 195 CVEs

rds: tcp: block BH in TCP callbacks
kexec: Improve & fix crash_exclude_mem_range() to handle overlapping ranges
module: correctly exit module_kallsyms_on_each_symbol when fn() != 0
module: potential uninitialized return in module_kallsyms_on_each_symbol()
module: use RCU to synchronize find_module
kallsyms: refactor {,module_}kallsyms_on_each_symbol
LTS tag: v5.4.295
scsi: qedf: Use designated initializer for struct qed_fcoe_cb_ops
arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() {CVE-2025-38320}
perf: Fix sample vs do_exit() {CVE-2025-38424}
s390/pci: Fix __pcilg_mio_inuser() inline assembly
rtc: test: Fix invalid format specifier.
jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() {CVE-2025-38337}
mm/huge_memory: fix dereferencing invalid pmd migration entry {CVE-2025-37958}
rtc: Make rtc_time64_to_tm() support dates before 1970
rtc: Improve performance of rtc_time64_to_tm(). Add tests.
xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create {CVE-2022-48773}
posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() {CVE-2025-38352}
ARM: dts: am335x-bone-common: Increase MDIO reset deassert delay to 50ms
ARM: dts: am335x-bone-common: Increase MDIO reset deassert time
ARM: dts: am335x-bone-common: Add GPIO PHY reset on revision C3 board
net: atm: fix /proc/net/atm/lec handling {CVE-2025-38180}
net: atm: add lec_mutex {CVE-2025-38323}
calipso: Fix null-ptr-deref in calipso_req_{set,del}attr(). {CVE-2025-38181}
tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer {CVE-2025-38184}
tcp: fix tcp_packet_delayed() for tcp_is_non_sack_preventing_reopen() behavior
atm: atmtcp: Free invalid length skb in atmtcp_c_send(). {CVE-2025-38185}
mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu(). {CVE-2025-38324}
wifi: carl9170: do not ping device which has failed to load firmware {CVE-2025-38420}
aoe: clean device rq_list in aoedev_downdev() {CVE-2025-38326}
hwmon: (occ) fix unaligned accesses
drm/nouveau/bl: increase buffer size to avoid truncate warning
erofs: remove unused trace event erofs_destroy_inode
ALSA: hda/realtek: enable headset mic on Latitude 5420 Rugged
ALSA: hda/intel: Add Thinkpad E15 to PM deny list
Input: sparcspkr - avoid unannotated fall-through
HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() {CVE-2025-38103}
atm: Revert atm_account_tx() if copy_from_iter_full() fails. {CVE-2025-38190}
selinux: fix selinux_xfrm_alloc_user() to set correct ctx_len
scsi: s390: zfcp: Ensure synchronous unit_add
scsi: storvsc: Increase the timeouts to storvsc_timeout
jffs2: check jffs2_prealloc_raw_node_refs() result in few other places {CVE-2025-38328}
jffs2: check that raw node were preallocated before writing summary {CVE-2025-38194}
drivers/rapidio/rio_cm.c: prevent possible heap overwrite {CVE-2025-38090}
powerpc/eeh: Fix missing PE bridge reconfiguration during VFIO EEH recovery
platform/x86: dell_rbu: Stop overwriting data buffer
platform: Add Surface platform directory
Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first"
tee: Prevent size calculation wraparound on 32-bit kernels
ARM: OMAP2+: Fix l4ls clk domain handling in STANDBY
bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS value
watchdog: da9052_wdt: respect TWDMIN
i40e: fix MMIO write access to an invalid page in i40e_clear_hw {CVE-2025-38200}
sock: Correct error checking condition for (assign|release)_proto_idx()
scsi: lpfc: Use memcpy() for BIOS version {CVE-2025-38332}
vxlan: Do not treat dst cache initialization errors as fatal
clk: rockchip: rk3036: mark ddrphy as critical
wifi: mac80211: do not offer a mesh path if forwarding is disabled
net: mlx4: add SOF_TIMESTAMPING_TX_SOFTWARE flag when getting ts info
pinctrl: armada-37xx: propagate error from armada_37xx_gpio_get()
pinctrl: armada-37xx:…

Record: CLSA-2025-1757963029
Updated: 2026-11-02

OSVCLSA-2026-1771081379 No score

kernel: Fix of 76 CVEs

HID: core: ensure the allocated report buffer can contain the reserved report ID {CVE-2025-38495}
fs/proc: fix uaf in proc_readdir_de() {CVE-2025-40271}
ALSA: usb-audio: Fix potential overflow of PCM transfer buffer {CVE-2025-40269}
Bluetooth: ISO: Fix possible UAF on iso_conn_free {CVE-2025-40141}
Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once {CVE-2025-40318}
smb3: fix for slab out of bounds on mount to ksmbd {CVE-2025-38728}
pptp: ensure minimal skb length in pptp_xmit() {CVE-2025-38574}
ipv6: reject malicious packets in ipv6_gso_segment() {CVE-2025-38572}
fbdev: fix potential buffer overflow in do_register_framebuffer() {CVE-2025-38702}
i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path {CVE-2025-39911}
bus: mhi: host: Detect events pointing to unexpected TREs {CVE-2025-39790}
nvmet: fix out-of-bounds access in nvmet_enable_port {CVE-2025-37825}
drm/xe: Make dma-fences compliant with the safe access rules {CVE-2025-38703}
libceph: fix invalid accesses to ceph_connection_v1_info {CVE-2025-39880}
fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass {CVE-2025-38396}
anon_inode: explicitly block ->setattr()
anon_inode: use a proper mode internally
dynamic_dname(): drop unused dentry argument
anon_inode: raise SB_I_NODEV and SB_I_NOEXEC
Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete {CVE-2025-38118}
Bluetooth: MGMT: Fix slab-use-after-free Read in mgmt_remove_adv_monitor_sync {CVE-2024-58013}
drm/xe: Fix vm_bind_ioctl double free bug {CVE-2025-38731}
media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format() {CVE-2025-38680}
HID: core: ensure __hid_request reserves the report ID as the first byte
wifi: mwifiex: Initialize the chan_stats array to zero {CVE-2025-39891}
i40e: Fix potential invalid access when MAC list is empty {CVE-2025-39853}
usb: core: config: Prevent OOB read in SS endpoint companion parsing {CVE-2025-39760}
fs/buffer: fix use-after-free when call bh_read() helper {CVE-2025-39691}
drm/i915: Protect access to driver and timeline name
sync_file: Protect access to driver and timeline name
dma-fence: Add safe access helpers and document the rules
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify {CVE-2025-38102}
net: phylink: add lock for serializing concurrent pl->phydev writes with resolver {CVE-2025-39905}
HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() {CVE-2025-39806}
vsock: Do not allow binding to VMADDR_PORT_ANY {CVE-2025-38618}
mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory {CVE-2025-39883}
md/raid1: Fix stack memory use after return in raid1_reshape {CVE-2025-38445}
drm/i915/gt: Fix timeline left held on VMA alloc error {CVE-2025-38389}
ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3() {CVE-2025-38249}
i40e: remove read access to debugfs files {CVE-2025-39901}
wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work {CVE-2025-39863}
bnxt_en: Fix memory corruption when FW resources change during ifdown {CVE-2025-39810}
atm: clip: Fix infinite recursive call of clip_push(). {CVE-2025-38459}
nbd: fix uaf in nbd_genl_connect() error path {CVE-2025-38443}
Squashfs: check return result of sb_min_blocksize {CVE-2025-38415}
vsock/vmci: Clear the vmci transport packet properly when initializing it {CVE-2025-38403}
regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods {CVE-2025-38395}
virtio-net: ensure the received length does not exceed allocated size {CVE-2025-38375}
ftrace: Fix UAF when lookup kallsym after ftrace disabled {CVE-2025-38346}
sctp: avoid NULL dereference when chunk data buffer is missing {CVE-2025-40240}
net: atm: fix /proc/net/atm/lec handling {CVE-2025-38180}
software node: Correct a OOB check in software_node_get_reference_args() {CVE-2025-38342}
net: atm: add lec_mutex {CVE-2025-38323} -…

Record: CLSA-2026-1771081379
Updated: 2026-11-02

OSVCLSA-2026-1771239384 No score

kernel: Fix of 75 CVEs

net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit {CVE-2025-39766}
NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL {CVE-2023-53680}
scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show() {CVE-2023-53676}
KVM: x86: use array_index_nospec with indices that come from guest {CVE-2025-39823}
ftrace: Also allocate and copy hash for reading of filter files {CVE-2025-39689}
ext4: improve error handling from ext4_dirhash() {CVE-2023-53473}
rcu: Protect ->defer_qs_iw_pending from data race {CVE-2025-39749}
ring-buffer: Fix deadloop issue on reading trace_pipe {CVE-2023-53668}
fs/proc: fix uaf in proc_readdir_de() {CVE-2025-40271}
ALSA: usb-audio: Fix potential overflow of PCM transfer buffer {CVE-2025-40269}
Bluetooth: ISO: Fix possible UAF on iso_conn_free {CVE-2025-40141}
pptp: ensure minimal skb length in pptp_xmit() {CVE-2025-38574}
lib: cpu_rmap: Avoid use after free on rmap->obj array entries {CVE-2023-53484}
ipv6: reject malicious packets in ipv6_gso_segment() {CVE-2025-38572}
fbdev: Fix vmalloc out-of-bounds write in fast_imageblit {CVE-2025-38685}
fbdev: fix potential buffer overflow in do_register_framebuffer() {CVE-2025-38702}
i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path {CVE-2025-39911}
libceph: fix invalid accesses to ceph_connection_v1_info {CVE-2025-39880}
bus: mhi: host: Detect events pointing to unexpected TREs {CVE-2025-39790}
nvmet: fix out-of-bounds access in nvmet_enable_port {CVE-2025-37825}
net: core: remove unnecessary frame_sz check in bpf_xdp_adjust_tail() {CVE-2023-54155}
wifi: mwifiex: Initialize the chan_stats array to zero {CVE-2025-39891}
i40e: Fix potential invalid access when MAC list is empty {CVE-2025-39853}
media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format() {CVE-2025-38680}
fs/buffer: fix use-after-free when call bh_read() helper {CVE-2025-39691}
net/mlx5: Devcom, fix error flow in mlx5_devcom_register_device {CVE-2023-54015}
x86/sev: Make enc_dec_hypercall() accept a size instead of npages {CVE-2023-53996}
page_pool: Fix use-after-free in page_pool_recycle_in_ring {CVE-2025-38129}
page_pool: fix inconsistency for page_pool_ring_[un]lock()
net: page_pool: use in_softirq() instead {CVE-2025-38129}
vsock: Ignore signal/timeout on connect() if already established {CVE-2025-40248}
vsock: avoid to close connected socket after the timeout {CVE-2025-40248}
sctp: avoid NULL dereference when chunk data buffer is missing {CVE-2025-40240}
smb: client: let recv_done verify data_offset, data_length and remaining_data_length {CVE-2025-39933}
net: phylink: add lock for serializing concurrent pl->phydev writes with resolver {CVE-2025-39905}
i40e: validate ring_len parameter against hardware-specific values
i40e: add validation for ring_len param {CVE-2025-39973}
i40e: increase max descriptors for XL710
i40e: remove read access to debugfs files {CVE-2025-39901}
mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory {CVE-2025-39883}
wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work {CVE-2025-39863}
i2c: tegra: check msg length in SMBUS block read {CVE-2025-38425}
regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods {CVE-2025-38395}
virtio-net: ensure the received length does not exceed allocated size {CVE-2025-38375}
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify {CVE-2025-38102}
vsock/vmci: Clear the vmci transport packet properly when initializing it {CVE-2025-38403}
can: bcm: add locking for bcm_op runtime updates {CVE-2025-38004}
scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflow {CVE-2023-54102}
tcp: fix a signed-integer-overflow bug in tcp_add_backlog() {CVE-2022-50865}
tcp: minor optimization in tcp_add_backlog() {CVE-2022-50865}
block, bfq: fix uaf for bfqq in bic_set_bfqq() {CVE-2023-52983}
block, bfq: replace 0/1 with…

Record: CLSA-2026-1771239384
Updated: 2026-11-02

OSV No score

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

In the Linux kernel, the following vulnerability has been resolved:

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().

This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before:

commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")

[will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]

Record: CVE-2025-38320
Updated: 2026-11-07

OSVMGASA-2025-0218 No score

Updated kernel-linus packages fix security vulnerabilities

Vanilla upstream kernel version 6.6.101 fixes bugs and vulnerabilities. For information about the vulnerabilities see the links.

Record: MGASA-2025-0218
Updated: 2026-11-02

OSVMGASA-2025-0219 No score

Updated kernel, kmod-virtualbox, kmod-xtables-addons & wireless-regdb packages fix security vulnerabilities

Upstream kernel version 6.6.101 fixes bugs and vulnerabilities. The kmod-virtualbox, kmod-xtables-addons & wireless-regdb packages have been updated to work with this new kernel. For information about the vulnerabilities see the links.

Record: MGASA-2025-0219
Updated: 2026-11-02

OSVUSN-7774-1 No score

linux, linux-aws, linux-aws-5.15, linux-gcp, linux-gcp-5.15, linux-gke, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-intel-iotg, linux-intel-iotg-5.15, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-5.15, linux-oracle, linux-raspi, linux-xilinx-zynqmp vulnerabilities