From: AL-KERNEL <[email protected]>
To: [email protected]
Subject: [CVE-2026-77771][IMPORTANT] <title>net/packet: fix slab-out-of-bounds access in packet_recvmsg()</title>
Date: Tue, 07 Jul 2026 14:41:06 -0400 [thread overview]
Message-ID: <[email protected]> (raw)
CVE: CVE-2026-77771
Priority: IMPORTANT
AL-KERNEL base severity: IMPORTANT
KPANIC flag: YES
Patch: <title>net/packet: fix slab-out-of-bounds access in packet_recvmsg()</title>
Commit: c700525fcc06b05adfea78039de02628af79e07a
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c700525fcc06b05adfea78039de02628af79e07a
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-77771
Analysis date: Tue, 07 Jul 2026 14:41:06 -0400
ActionableScore: 8
ActionableScore lower bound: 7
Actionable bucket: Strong Important candidate / Actionable Moderate at minimum
Manual review required: YES
Summary:
A local AF_PACKET user can trigger a kernel stack out-of-bounds write in `packet_recvmsg()` when `PACKET_COPY_THRESH` and packet mmap cause copied skb objects to carry garbage `skb->cb[]` metadata, leading to kernel crash and plausible local privilege escalation risk.
======================================================================
ABOUT THIS REPORT
======================================================================
The original Linux kernel CVE announcement for CVE-2026-77771 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-77771
The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.
This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.
The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.
Published priority for this report: IMPORTANT
Manual review required: YES
A detailed explanation of the methodology and priority rules is included
at the end of this message.
======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================
CVE-2026-77771 IMPORTANT CHECK WITH IMPACT FROM ORIG NN IMPORTANT Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-787;CWE-121;*CWE-457;Other CVSS 'AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7.8';DESCR 'An AF_PACKET receive path bug can corrupt the kernel stack because packet_recvmsg copies PACKET_SKB_CB(skb).sa into msg_name using a length derived from packet metadata that may contain garbage for copied skb objects. A local process can trigger this with PACKET_COPY_THRESH and packet mmap so that tpacket_rcv queues a copied skb with stale skb cb contents, then recvmsg can perform an oversized copy into the sockaddr_storage buffer. For the CVSS the PR:L is used because reliable triggering requires a local process and AF_PACKET socket capability, which may be available through user namespaces or delegated CAP_NET_RAW rather than full root. The issue is not directly network reachable because remote packets alone do not create the AF_PACKET socket or the mmap configuration. Impact is at least local denial of service via kernel crash and in worst case may allow confidentiality or integrity impact because the primitive is a kernel stack out of bounds write.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Strong Important candidate / Actionable Moderate at minimum (with actual score 8) MAYBE REMOTE WRITE KASAN OOB KERNEL_PANIC_PLUS_UAF HARDWARE LINUS SYZBOT KPANIC PACKET - - checked
======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================
ActionableScore=8
ActionableScoreLower=7
## 1. ActionableScore
* Conservative score: 7
* Paranoid score: 8
* Final recommended bucket: **Strong Important candidate / Actionable Moderate at minimum**
## 2. Signal breakdown
Triggered signals:
* Local unprivileged trigger: +1
AF_PACKET requires CAP_NET_RAW, but this may be reachable by local users through user namespaces or delegated capabilities in some deployments.
* Generic memory corruption, strong corruption primitive: +2
The KASAN report shows a concrete kernel stack out-of-bounds write in `packet_recvmsg()` via `memcpy()`.
* Weak LPE concern: +1 conservative, +2 paranoid
The primitive is a kernel stack OOB write, which is more serious than a NULL dereference or pure DoS. However, the overwrite payload and target appear constrained and not clearly attacker-selected, so conservative scoring treats LPE as plausible but not demonstrated.
* Reliable kernel crash / strong DoS: +1
syzbot reproduced a KASAN stack-out-of-bounds write and the bug is reachable through a normal syscall path.
* Local high-control kernel data-plane API refinement: +1
AF_PACKET with packet mmap and `PACKET_COPY_THRESH` gives a local process significant control over packet receive paths and buffer/ring behavior.
* Confidentiality impact plausible: +1
The bug involves copying from garbage `skb->cb[]` metadata and unsafe length handling. Direct disclosure is not proven, but stack corruption and kernel metadata misuse justify limited concern.
* Integrity impact plausible: +1
Kernel stack overwrite gives plausible integrity impact, although no controlled arbitrary write is demonstrated.
* Broad/default/common subsystem exposure: +1
AF_PACKET is a widely available networking facility, even though socket creation is capability-gated.
Subtract / limiting signals:
* Corruption primitive constrained or metadata-derived: -1
The overwritten data is derived from stale or garbage packet control metadata, and the patch does not show a fully attacker-controlled payload or arbitrary target selection.
## 3. Reachability analysis
A local process can trigger the bug by creating an AF_PACKET socket, enabling packet mmap behavior, using `PACKET_COPY_THRESH`, and then receiving packets through the affected path. In typical host deployments this requires CAP_NET_RAW, but user namespaces or delegated network capabilities can reduce the practical privilege requirement to a local unprivileged user in some configurations.
The issue is not directly remote reachable. Remote packets may participate in the receive path, but an attacker still needs a local AF_PACKET socket and the relevant packet mmap setup on the victim system.
The path is not exotic. AF_PACKET is a common Linux networking interface, and packet mmap is a normal supported mode. Exploitability is still constrained by capability requirements and by the apparent lack of a clearly controlled overwrite payload.
## 4. Severity interpretation
This behaves above ordinary Moderate because the patch fixes a concrete kernel stack out-of-bounds write, not just a warning, leak, or NULL dereference. Realistic impact is at least local kernel crash / DoS.
Privilege escalation is plausible but not demonstrated. The strongest evidence is the kernel stack OOB write in a syscall receive path. The main limiting factor is that the copied data comes from garbage or stale `skb->cb[]` metadata, so attacker control over the exact overwrite content and target is unclear.
Overall this should be treated as a Strong Important candidate, or at minimum an Actionable Moderate that should not be auto-closed.
## 5. One-sentence report phrase
A local AF_PACKET user can trigger a kernel stack out-of-bounds write in `packet_recvmsg()` when `PACKET_COPY_THRESH` and packet mmap cause copied skb objects to carry garbage `skb->cb[]` metadata, leading to kernel crash and plausible local privilege escalation risk.
## 6. Manual review recommendation
MANUAL CHECK REQUIRED
This is a concrete kernel stack memory corruption bug in a networking syscall path, with plausible LPE risk even though the overwrite appears constrained and full exploitability is not proven.
======================================================================
UPSTREAM PATCH SUMMARY
======================================================================
Patch: <title>net/packet: fix slab-out-of-bounds access in packet_recvmsg()</title>
Commit: c700525fcc06b05adfea78039de02628af79e07a
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c700525fcc06b05adfea78039de02628af79e07a
Commit description:
syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH
and mmap operations, tpacket_rcv() is queueing skbs with
garbage in skb->cb[], triggering a too big copy [1]
Presumably, users of af_packet using mmap() already gets correct
metadata from the mapped buffer, we can simply make sure
to clear 12 bytes that might be copied to user space later.
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]
BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489
Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631
CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189
memcpy+0x39/0x60 mm/kasan/shadow.c:66
memcpy include/linux/fortify-string.h:225 [inline]
packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489
sock_recvmsg_nosec net/socket.c:948 [inline]
sock_recvmsg net/socket.c:966 [inline]
sock_recvmsg net/socket.c:962 [inline]
____sys_recvmsg+0x2c4/0x600 net/socket.c:2632
___sys_recvmsg+0x127/0x200 net/socket.c:2674
__sys_recvmsg+0xe2/0x1a0 net/socket.c:2704
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fdfd5954c29
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29
RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005
RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60
R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54
</TASK>
addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame:
____sys_recvmsg+0x0/0x600 include/linux/uio.h:246
this frame has 1 object:
[32, 160) 'addr'
Memory state around the buggy address:
ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00
ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
>ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3
^
ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1
ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00
==================================================================
Fixes: 0fb375fb9b93 ("[AF_PACKET]: Allow for > 8 byte hardware addresses.")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Changed files:
net/packet/af_packet.c
Diff excerpt:
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index ab87f22cc7ecd..a7273af2d9009 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2317,8 +2317,11 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
copy_skb = skb_get(skb);
skb_head = skb->data;
}
- if (copy_skb)
+ if (copy_skb) {
+ memset(&PACKET_SKB_CB(copy_skb)->sa.ll, 0,
+ sizeof(PACKET_SKB_CB(copy_skb)->sa.ll));
skb_set_owner_r(copy_skb, sk);
+ }
}
snaplen = po->rx_ring.frame_size - macoff;
if ((int)snaplen < 0) {
@@ -3462,6 +3465,8 @@ static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
sock_recv_ts_and_drops(msg, sk, skb);
if (msg->msg_name) {
+ const size_t max_len = min(sizeof(skb->cb),
+ sizeof(struct sockaddr_storage));
int copy_len;
/* If the address length field is there to be filled
@@ -3484,6 +3489,10 @@ static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
msg->msg_namelen = sizeof(struct sockaddr_ll);
}
}
+ if (WARN_ON_ONCE(copy_len > max_len)) {
+ copy_len = max_len;
+ msg->msg_namelen = copy_len;
+ }
memcpy(msg->msg_name, &PACKET_SKB_CB(skb)->sa, copy_len);
}
generated by cgit 1.3-korg (git 2.53.0) at 2026-07-07 18:40:34 +0000
Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c700525fcc06b05adfea78039de02628af79e07a
======================================================================
DETAILED REPORT METHODOLOGY
======================================================================
The original Linux kernel CVE announcement for CVE-2026-77771 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-77771
The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.
The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.
This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.
The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.
Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:
Conservative CVSS vector: AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
The Best / paranoid CVSS vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
The Best / paranoid CVSS score: 7.8
The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.
CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.
A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.
Conservative ActionableScore: 7
Paranoid ActionableScore: 8
The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.
For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:
ActionableScore below 5 -> MODERATE REGULAR
ActionableScore 5 or more -> MODERATE 7.0
The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.
There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).
KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.
AL-KERNEL base severity for this report: IMPORTANT
KPANIC detected for this report: YES
Published priority for this report (same as in Subject): IMPORTANT
These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).
Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is [email protected] (and both
send reply to CVE record itself too and see "reply" button below for howto reply).
reply other threads:[~2026-07-07 18:41 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --from, and --in-reply-to
switches of git-send-email(1) and next cmd tested by kernelcve.org admin:
git send-email --smtp-server=mail.kernelcve.org --smtp-server-port=25 --smtp-auth=none --from='Your Name <youremail@domain.is>' --suppress-cc=all --no-cc \
--in-reply-to=cve-2026-77771.0a40ac265677c60596c775a4@kernelcve.org \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
The file with msg could look like this then:
cat YOUR_REPLY
Subject: Re: [CVE-2026-64206][MODERATE REGULAR] Bluetooth: L2CAP test
Just testing public-inbox replies.
Thanks,
MyName
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox