From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-77771][IMPORTANT] net/packet: fix slab-out-of-bounds access in packet_recvmsg() Date: Tue, 07 Jul 2026 14:41:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-77771 X-AL-KERNEL-Priority: IMPORTANT X-AL-KERNEL-Severity: IMPORTANT X-AL-KERNEL-Base-Severity: IMPORTANT X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 8 X-AL-KERNEL-ActionableScore-Lower: 7 X-AL-KERNEL-Commit: c700525fcc06b05adfea78039de02628af79e07a List-Id: CVE: CVE-2026-77771 Priority: IMPORTANT AL-KERNEL base severity: IMPORTANT KPANIC flag: YES Patch: net/packet: fix slab-out-of-bounds access in packet_recvmsg() 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: net/packet: fix slab-out-of-bounds access in packet_recvmsg() 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: __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 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 Reported-by: syzbot Link: https://lore.kernel.org/r/20220312232958.3535620-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski 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 alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).