CWE-125
AllowedOut-of-bounds Read
Abstraction: Base · Status: Draft
The product reads data past the end, or before the beginning, of the intended buffer.
11292 vulnerabilities reference this CWE, most recent first.
GHSA-P3RG-VMCM-JWV4
Vulnerability from github – Published: 2023-08-23 03:30 – Updated: 2024-03-21 03:35** UNSUPPPORTED WHEN ASSIGNED ** ** UNSUPPORTED WHEN ASSIGNED ** Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in Hitachi EH-VIEW (KeypadDesigner) allows local attackers to potentially disclose information and execute arbitray code on affected EH-VIEW installations. User interaction is required to exploit the vulnerabilities in that the user must open a malicious file. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
{
"affected": [],
"aliases": [
"CVE-2023-39984"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-23T02:15:08Z",
"severity": "HIGH"
},
"details": "** UNSUPPPORTED WHEN ASSIGNED ** ** UNSUPPORTED WHEN ASSIGNED ** Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in Hitachi EH-VIEW (KeypadDesigner) allows local attackers to potentially disclose information and execute arbitray code on affected EH-VIEW installations. User interaction is required to exploit the vulnerabilities in that the user must open a malicious file. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.\n",
"id": "GHSA-p3rg-vmcm-jwv4",
"modified": "2024-03-21T03:35:41Z",
"published": "2023-08-23T03:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39984"
},
{
"type": "WEB",
"url": "https://www.hitachi.com/hirt/hitachi-sec/2023/002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P3W6-65M5-G9QX
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2025-04-20 03:41The xps_decode_font_char_imp function in xps/xpsfont.c in Artifex Ghostscript GhostXPS 9.21 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) or possibly have unspecified other impact via a crafted document.
{
"affected": [],
"aliases": [
"CVE-2017-9740"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-26T19:29:00Z",
"severity": "HIGH"
},
"details": "The xps_decode_font_char_imp function in xps/xpsfont.c in Artifex Ghostscript GhostXPS 9.21 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) or possibly have unspecified other impact via a crafted document.",
"id": "GHSA-p3w6-65m5-g9qx",
"modified": "2025-04-20T03:41:28Z",
"published": "2022-05-13T01:48:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9740"
},
{
"type": "WEB",
"url": "https://bugs.ghostscript.com/show_bug.cgi?id=698064"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201811-12"
},
{
"type": "WEB",
"url": "http://git.ghostscript.com/?p=ghostpdl.git%3Ba=commit%3Bh=961b10cdd71403072fb99401a45f3bef6ce53626"
},
{
"type": "WEB",
"url": "http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=961b10cdd71403072fb99401a45f3bef6ce53626"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99983"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P3X3-P9PR-Q9WV
Vulnerability from github – Published: 2022-05-14 00:53 – Updated: 2022-05-14 00:53Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have an Out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.
{
"affected": [],
"aliases": [
"CVE-2018-5048"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-20T19:29:00Z",
"severity": "MODERATE"
},
"details": "Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have an Out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.",
"id": "GHSA-p3x3-p9pr-q9wv",
"modified": "2022-05-14T00:53:23Z",
"published": "2022-05-14T00:53:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5048"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/acrobat/apsb18-21.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104699"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1041250"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P3XV-XH73-GW2R
Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22In libsixel v1.8.2, there is a heap-based buffer over-read in the function load_jpeg() in the file loader.c, as demonstrated by img2sixel.
{
"affected": [],
"aliases": [
"CVE-2019-3574"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-02T15:29:00Z",
"severity": "HIGH"
},
"details": "In libsixel v1.8.2, there is a heap-based buffer over-read in the function load_jpeg() in the file loader.c, as demonstrated by img2sixel.",
"id": "GHSA-p3xv-xh73-gw2r",
"modified": "2022-05-13T01:22:27Z",
"published": "2022-05-13T01:22:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3574"
},
{
"type": "WEB",
"url": "https://github.com/saitoha/libsixel/issues/83"
},
{
"type": "WEB",
"url": "https://github.com/TeamSeri0us/pocs/tree/master/libsixel"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P42F-M78X-844R
Vulnerability from github – Published: 2025-10-31 12:30 – Updated: 2025-11-05 00:31[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]
Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in one of three formats. Xen has boundary checking bugs with all three formats, which can cause out-of-bounds reads and writes while processing the inputs.
-
CVE-2025-58147. Hypercalls using the HV_VP_SET Sparse format can cause vpmask_set() to write out of bounds when converting the bitmap to Xen's format.
-
CVE-2025-58148. Hypercalls using any input format can cause send_ipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer.
{
"affected": [],
"aliases": [
"CVE-2025-58148"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-31T12:15:35Z",
"severity": "HIGH"
},
"details": "[This CNA information record relates to multiple CVEs; the\ntext explains which aspects/vulnerabilities correspond to which CVE.]\n\nSome Viridian hypercalls can specify a mask of vCPU IDs as an input, in\none of three formats. Xen has boundary checking bugs with all three\nformats, which can cause out-of-bounds reads and writes while processing\nthe inputs.\n\n * CVE-2025-58147. Hypercalls using the HV_VP_SET Sparse format can\n cause vpmask_set() to write out of bounds when converting the bitmap\n to Xen\u0027s format.\n\n * CVE-2025-58148. Hypercalls using any input format can cause\n send_ipi() to read d-\u003evcpu[] out-of-bounds, and operate on a wild\n vCPU pointer.",
"id": "GHSA-p42f-m78x-844r",
"modified": "2025-11-05T00:31:32Z",
"published": "2025-10-31T12:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58148"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-475.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/10/21/1"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-475.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P437-J6G9-3F2F
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2025-04-08 21:31In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: x86: Don't overflow lpage_info when checking attributes
Fix KVM_SET_MEMORY_ATTRIBUTES to not overflow lpage_info array and trigger KASAN splat, as seen in the private_mem_conversions_test selftest.
When memory attributes are set on a GFN range, that range will have specific properties applied to the TDP. A huge page cannot be used when the attributes are inconsistent, so they are disabled for those the specific huge pages. For internal KVM reasons, huge pages are also not allowed to span adjacent memslots regardless of whether the backing memory could be mapped as huge.
What GFNs support which huge page sizes is tracked by an array of arrays 'lpage_info' on the memslot, of ‘kvm_lpage_info’ structs. Each index of lpage_info contains a vmalloc allocated array of these for a specific supported page size. The kvm_lpage_info denotes whether a specific huge page (GFN and page size) on the memslot is supported. These arrays include indices for unaligned head and tail huge pages.
Preventing huge pages from spanning adjacent memslot is covered by incrementing the count in head and tail kvm_lpage_info when the memslot is allocated, but disallowing huge pages for memory that has mixed attributes has to be done in a more complicated way. During the KVM_SET_MEMORY_ATTRIBUTES ioctl KVM updates lpage_info for each memslot in the range that has mismatched attributes. KVM does this a memslot at a time, and marks a special bit, KVM_LPAGE_MIXED_FLAG, in the kvm_lpage_info for any huge page. This bit is essentially a permanently elevated count. So huge pages will not be mapped for the GFN at that page size if the count is elevated in either case: a huge head or tail page unaligned to the memslot or if KVM_LPAGE_MIXED_FLAG is set because it has mixed attributes.
To determine whether a huge page has consistent attributes, the KVM_SET_MEMORY_ATTRIBUTES operation checks an xarray to make sure it consistently has the incoming attribute. Since level - 1 huge pages are aligned to level huge pages, it employs an optimization. As long as the level - 1 huge pages are checked first, it can just check these and assume that if each level - 1 huge page contained within the level sized huge page is not mixed, then the level size huge page is not mixed. This optimization happens in the helper hugepage_has_attrs().
Unfortunately, although the kvm_lpage_info array representing page size 'level' will contain an entry for an unaligned tail page of size level, the array for level - 1 will not contain an entry for each GFN at page size level. The level - 1 array will only contain an index for any unaligned region covered by level - 1 huge page size, which can be a smaller region. So this causes the optimization to overflow the level - 1 kvm_lpage_info and perform a vmalloc out of bounds read.
In some cases of head and tail pages where an overflow could happen, callers skip the operation completely as KVM_LPAGE_MIXED_FLAG is not required to prevent huge pages as discussed earlier. But for memslots that are smaller than the 1GB page size, it does call hugepage_has_attrs(). In this case the huge page is both the head and tail page. The issue can be observed simply by compiling the kernel with CONFIG_KASAN_VMALLOC and running the selftest “private_mem_conversions_test”, which produces the output like the following:
BUG: KASAN: vmalloc-out-of-bounds in hugepage_has_attrs+0x7e/0x110 Read of size 4 at addr ffffc900000a3008 by task private_mem_con/169 Call Trace: dump_stack_lvl print_report ? __virt_addr_valid ? hugepage_has_attrs ? hugepage_has_attrs kasan_report ? hugepage_has_attrs hugepage_has_attrs kvm_arch_post_set_memory_attributes kvm_vm_ioctl
It is a little ambiguous whether the unaligned head page (in the bug case also the tail page) should be expected to have KVM_LPAGE_MIXED_FLAG set. It is not functionally required, as the unal ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26991"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: x86: Don\u0027t overflow lpage_info when checking attributes\n\nFix KVM_SET_MEMORY_ATTRIBUTES to not overflow lpage_info array and trigger\nKASAN splat, as seen in the private_mem_conversions_test selftest.\n\nWhen memory attributes are set on a GFN range, that range will have\nspecific properties applied to the TDP. A huge page cannot be used when\nthe attributes are inconsistent, so they are disabled for those the\nspecific huge pages. For internal KVM reasons, huge pages are also not\nallowed to span adjacent memslots regardless of whether the backing memory\ncould be mapped as huge.\n\nWhat GFNs support which huge page sizes is tracked by an array of arrays\n\u0027lpage_info\u0027 on the memslot, of \u2018kvm_lpage_info\u2019 structs. Each index of\nlpage_info contains a vmalloc allocated array of these for a specific\nsupported page size. The kvm_lpage_info denotes whether a specific huge\npage (GFN and page size) on the memslot is supported. These arrays include\nindices for unaligned head and tail huge pages.\n\nPreventing huge pages from spanning adjacent memslot is covered by\nincrementing the count in head and tail kvm_lpage_info when the memslot is\nallocated, but disallowing huge pages for memory that has mixed attributes\nhas to be done in a more complicated way. During the\nKVM_SET_MEMORY_ATTRIBUTES ioctl KVM updates lpage_info for each memslot in\nthe range that has mismatched attributes. KVM does this a memslot at a\ntime, and marks a special bit, KVM_LPAGE_MIXED_FLAG, in the kvm_lpage_info\nfor any huge page. This bit is essentially a permanently elevated count.\nSo huge pages will not be mapped for the GFN at that page size if the\ncount is elevated in either case: a huge head or tail page unaligned to\nthe memslot or if KVM_LPAGE_MIXED_FLAG is set because it has mixed\nattributes.\n\nTo determine whether a huge page has consistent attributes, the\nKVM_SET_MEMORY_ATTRIBUTES operation checks an xarray to make sure it\nconsistently has the incoming attribute. Since level - 1 huge pages are\naligned to level huge pages, it employs an optimization. As long as the\nlevel - 1 huge pages are checked first, it can just check these and assume\nthat if each level - 1 huge page contained within the level sized huge\npage is not mixed, then the level size huge page is not mixed. This\noptimization happens in the helper hugepage_has_attrs().\n\nUnfortunately, although the kvm_lpage_info array representing page size\n\u0027level\u0027 will contain an entry for an unaligned tail page of size level,\nthe array for level - 1 will not contain an entry for each GFN at page\nsize level. The level - 1 array will only contain an index for any\nunaligned region covered by level - 1 huge page size, which can be a\nsmaller region. So this causes the optimization to overflow the level - 1\nkvm_lpage_info and perform a vmalloc out of bounds read.\n\nIn some cases of head and tail pages where an overflow could happen,\ncallers skip the operation completely as KVM_LPAGE_MIXED_FLAG is not\nrequired to prevent huge pages as discussed earlier. But for memslots that\nare smaller than the 1GB page size, it does call hugepage_has_attrs(). In\nthis case the huge page is both the head and tail page. The issue can be\nobserved simply by compiling the kernel with CONFIG_KASAN_VMALLOC and\nrunning the selftest \u201cprivate_mem_conversions_test\u201d, which produces the\noutput like the following:\n\nBUG: KASAN: vmalloc-out-of-bounds in hugepage_has_attrs+0x7e/0x110\nRead of size 4 at addr ffffc900000a3008 by task private_mem_con/169\nCall Trace:\n dump_stack_lvl\n print_report\n ? __virt_addr_valid\n ? hugepage_has_attrs\n ? hugepage_has_attrs\n kasan_report\n ? hugepage_has_attrs\n hugepage_has_attrs\n kvm_arch_post_set_memory_attributes\n kvm_vm_ioctl\n\nIt is a little ambiguous whether the unaligned head page (in the bug case\nalso the tail page) should be expected to have KVM_LPAGE_MIXED_FLAG set.\nIt is not functionally required, as the unal\n---truncated---",
"id": "GHSA-p437-j6g9-3f2f",
"modified": "2025-04-08T21:31:30Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26991"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/048cc4a028e635d339687ed968985d2d1669494c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/992b54bd083c5bee24ff7cc35991388ab08598c4"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P43W-G3C5-G5MQ
Vulnerability from github – Published: 2021-03-29 16:35 – Updated: 2024-10-09 20:12An issue was discovered in Pillow before 8.1.1. There is an out-of-bounds read in SGIRleDecode.c.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Pillow"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0"
},
{
"fixed": "8.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-25293"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-22T22:07:38Z",
"nvd_published_at": "2021-03-19T04:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Pillow before 8.1.1. There is an out-of-bounds read in SGIRleDecode.c.",
"id": "GHSA-p43w-g3c5-g5mq",
"modified": "2024-10-09T20:12:53Z",
"published": "2021-03-29T16:35:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25293"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/4853e522bddbec66022c0915b9a56255d0188bf9"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/f891baa604636cd2506a9360d170bc2cf4963cc5"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-p43w-g3c5-g5mq"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pillow/PYSEC-2021-39.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/python-pillow/Pillow"
},
{
"type": "WEB",
"url": "https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202107-33"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Out of bounds read in Pillow"
}
GHSA-P43X-Q875-62RR
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-03-25 18:31In the Linux kernel, the following vulnerability has been resolved:
e1000: fix OOB in e1000_tbi_should_accept()
In e1000_tbi_should_accept() we read the last byte of the frame via 'data[length - 1]' to evaluate the TBI workaround. If the descriptor- reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq):
================================================================== BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790 Read of size 1 at addr ffff888014114e54 by task sshd/363
CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f511b476b10 Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24 RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10 RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003 RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00 R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30 The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800] The buggy address belongs to the physical page: page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110 head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x100000000010200(slab|head|node=0|zone=1) raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000 raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected ==================================================================
This happens because the TBI check unconditionally dereferences the last byte without validating the reported length first:
u8 last_byte = *(data + length - 1);
Fix by rejecting the frame early if the length is zero, or if it exceeds adapter->rx_buffer_len. This preserves the TBI workaround semantics for valid frames and prevents touching memory beyond the RX buffer.
{
"affected": [],
"aliases": [
"CVE-2025-71093"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T16:16:09Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ne1000: fix OOB in e1000_tbi_should_accept()\n\nIn e1000_tbi_should_accept() we read the last byte of the frame via\n\u0027data[length - 1]\u0027 to evaluate the TBI workaround. If the descriptor-\nreported length is zero or larger than the actual RX buffer size, this\nread goes out of bounds and can hit unrelated slab objects. The issue\nis observed from the NAPI receive path (e1000_clean_rx_irq):\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790\nRead of size 1 at addr ffff888014114e54 by task sshd/363\n\nCPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u003cIRQ\u003e\n dump_stack_lvl+0x5a/0x74\n print_address_description+0x7b/0x440\n print_report+0x101/0x200\n kasan_report+0xc1/0xf0\n e1000_tbi_should_accept+0x610/0x790\n e1000_clean_rx_irq+0xa8c/0x1110\n e1000_clean+0xde2/0x3c10\n __napi_poll+0x98/0x380\n net_rx_action+0x491/0xa20\n __do_softirq+0x2c9/0x61d\n do_softirq+0xd1/0x120\n \u003c/IRQ\u003e\n \u003cTASK\u003e\n __local_bh_enable_ip+0xfe/0x130\n ip_finish_output2+0x7d5/0xb00\n __ip_queue_xmit+0xe24/0x1ab0\n __tcp_transmit_skb+0x1bcb/0x3340\n tcp_write_xmit+0x175d/0x6bd0\n __tcp_push_pending_frames+0x7b/0x280\n tcp_sendmsg_locked+0x2e4f/0x32d0\n tcp_sendmsg+0x24/0x40\n sock_write_iter+0x322/0x430\n vfs_write+0x56c/0xa60\n ksys_write+0xd1/0x190\n do_syscall_64+0x43/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f511b476b10\nCode: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 \u003c48\u003e 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24\nRSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10\nRDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003\nRBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00\nR10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003\n \u003c/TASK\u003e\nAllocated by task 1:\n __kasan_krealloc+0x131/0x1c0\n krealloc+0x90/0xc0\n add_sysfs_param+0xcb/0x8a0\n kernel_add_sysfs_param+0x81/0xd4\n param_sysfs_builtin+0x138/0x1a6\n param_sysfs_init+0x57/0x5b\n do_one_initcall+0x104/0x250\n do_initcall_level+0x102/0x132\n do_initcalls+0x46/0x74\n kernel_init_freeable+0x28f/0x393\n kernel_init+0x14/0x1a0\n ret_from_fork+0x22/0x30\nThe buggy address belongs to the object at ffff888014114000\n which belongs to the cache kmalloc-2k of size 2048\nThe buggy address is located 1620 bytes to the right of\n 2048-byte region [ffff888014114000, ffff888014114800]\nThe buggy address belongs to the physical page:\npage:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110\nhead:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0\nflags: 0x100000000010200(slab|head|node=0|zone=1)\nraw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000\nraw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n==================================================================\n\nThis happens because the TBI check unconditionally dereferences the last\nbyte without validating the reported length first:\n\n\tu8 last_byte = *(data + length - 1);\n\nFix by rejecting the frame early if the length is zero, or if it exceeds\nadapter-\u003erx_buffer_len. This preserves the TBI workaround semantics for\nvalid frames and prevents touching memory beyond the RX buffer.",
"id": "GHSA-p43x-q875-62rr",
"modified": "2026-03-25T18:31:34Z",
"published": "2026-01-13T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71093"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26c8bebc2f25288c2bcac7bc0a7662279a0e817c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/278b7cfe0d4da7502c7fd679b15032f014c92892"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c4c0c09f9648ba766d399917d420d03e7b3e1f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ccfa56f272241e8d8e2c38191fdbb03df489d80"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c72a5182ed92904d01057f208c390a303f00a0f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad7a2a45e2417ac54089926b520924f8f0d91aea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee7c125fb3e8b04dd46510130b9fc92380e5d578"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P444-7JHX-8PP4
Vulnerability from github – Published: 2023-06-28 18:30 – Updated: 2024-04-04 05:15In multiple files, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure in the wifi server with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-262246231
{
"affected": [],
"aliases": [
"CVE-2023-21204"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-28T18:15:15Z",
"severity": "MODERATE"
},
"details": "In multiple files, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure in the wifi server with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-262246231",
"id": "GHSA-p444-7jhx-8pp4",
"modified": "2024-04-04T05:15:42Z",
"published": "2023-06-28T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21204"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-06-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P462-H7Q3-M5GX
Vulnerability from github – Published: 2022-05-24 16:52 – Updated: 2024-04-04 01:33Processing a specially crafted project file in LAquis SCADA 4.3.1.71 may trigger an out-of-bounds read, which may allow an attacker to obtain sensitive information. The attacker must have local access to the system. A CVSS v3 base score of 2.5 has been calculated; the CVSS vector string is (AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N).
{
"affected": [],
"aliases": [
"CVE-2019-10994"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-05T19:15:00Z",
"severity": "MODERATE"
},
"details": "Processing a specially crafted project file in LAquis SCADA 4.3.1.71 may trigger an out-of-bounds read, which may allow an attacker to obtain sensitive information. The attacker must have local access to the system. A CVSS v3 base score of 2.5 has been calculated; the CVSS vector string is (AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N).",
"id": "GHSA-p462-h7q3-m5gx",
"modified": "2024-04-04T01:33:10Z",
"published": "2022-05-24T16:52:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10994"
},
{
"type": "WEB",
"url": "https://www.us-cert.gov/ics/advisories/icsa-19-213-06"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.
Mitigation
Strategy: Language Selection
Use a language that provides appropriate memory abstractions.
CAPEC-540: Overread Buffers
An adversary attacks a target by providing input that causes an application to read beyond the boundary of a defined buffer. This typically occurs when a value influencing where to start or stop reading is set to reflect positions outside of the valid memory location of the buffer. This type of attack may result in exposure of sensitive information, a system crash, or arbitrary code execution.