CWE-476
AllowedNULL Pointer Dereference
Abstraction: Base · Status: Stable
The product dereferences a pointer that it expects to be valid but is NULL.
6310 vulnerabilities reference this CWE, most recent first.
GHSA-V22F-RW8M-47VR
Vulnerability from github – Published: 2024-06-21 12:31 – Updated: 2025-09-17 18:31In the Linux kernel, the following vulnerability has been resolved:
greybus: lights: check return of get_channel_from_mode
If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places.
This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE.
[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru
{
"affected": [],
"aliases": [
"CVE-2024-38637"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-21T11:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngreybus: lights: check return of get_channel_from_mode\n\nIf channel for the given node is not found we return null from\nget_channel_from_mode. Make sure we validate the return pointer\nbefore using it in two of the missing places.\n\nThis was originally reported in [0]:\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru",
"id": "GHSA-v22f-rw8m-47vr",
"modified": "2025-09-17T18:31:14Z",
"published": "2024-06-21T12:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38637"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/330f6bcdcef03f70f81db5f2ed6747af656a09f2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/518e2c46b5dbce40b1aa0100001d03c3ceaa7d38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/895cdd9aa9546523df839f9cc1488a0ecc1e0731"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8f4a76d477f0cc3c54d512f07f6f88c8e1c1e07b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b41a9b9c8be8c552f10633453fdb509e83b66f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1ba19a1ae7cd1e324685ded4ab563e78fe68648"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2c64246e5dc8c0d35ec41770b85e2b4cafdff21"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eac10cf3a97ffd4b4deb0a29f57c118225a42850"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"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-V22H-74VW-3J73
Vulnerability from github – Published: 2026-05-19 06:30 – Updated: 2026-05-19 06:30NULL pointer dereference vulnerability in Samsung Open Source Walrus allows Pointer Manipulation.
This issue affects Walrus: f339b8ee4ea701772e8ae640b3d1b12ac02b1ae9.
{
"affected": [],
"aliases": [
"CVE-2026-47308"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-19T05:16:25Z",
"severity": "MODERATE"
},
"details": "NULL pointer dereference vulnerability in Samsung Open Source Walrus allows Pointer Manipulation.\n\nThis issue affects Walrus: f339b8ee4ea701772e8ae640b3d1b12ac02b1ae9.",
"id": "GHSA-v22h-74vw-3j73",
"modified": "2026-05-19T06:30:30Z",
"published": "2026-05-19T06:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47308"
},
{
"type": "WEB",
"url": "https://github.com/Samsung/walrus/pull/409"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V22X-X62X-Q5QJ
Vulnerability from github – Published: 2024-02-13 18:38 – Updated: 2024-02-13 18:38Windows Lightweight Directory Access Protocol (LDAP) Denial of Service Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-21356"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-13T18:15:52Z",
"severity": "MODERATE"
},
"details": "Windows Lightweight Directory Access Protocol (LDAP) Denial of Service Vulnerability",
"id": "GHSA-v22x-x62x-q5qj",
"modified": "2024-02-13T18:38:23Z",
"published": "2024-02-13T18:38:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21356"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21356"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V237-VCGW-685X
Vulnerability from github – Published: 2022-05-14 03:52 – Updated: 2025-04-20 03:46read_formatted_entries in dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29, does not properly validate the format count, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted ELF file, related to concat_filename.
{
"affected": [],
"aliases": [
"CVE-2017-15023"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-05T01:29:00Z",
"severity": "MODERATE"
},
"details": "read_formatted_entries in dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29, does not properly validate the format count, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted ELF file, related to concat_filename.",
"id": "GHSA-v237-vcgw-685x",
"modified": "2025-04-20T03:46:20Z",
"published": "2022-05-14T03:52:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15023"
},
{
"type": "WEB",
"url": "https://blogs.gentoo.org/ago/2017/10/03/binutils-null-pointer-dereference-in-concat_filename-dwarf2-c"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201801-01"
},
{
"type": "WEB",
"url": "https://sourceware.org/bugzilla/show_bug.cgi?id=22200"
},
{
"type": "WEB",
"url": "https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git%3Bh=c361faae8d964db951b7100cada4dcdc983df1bf"
},
{
"type": "WEB",
"url": "https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c361faae8d964db951b7100cada4dcdc983df1bf"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/101611"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V25M-V785-G666
Vulnerability from github – Published: 2025-07-09 03:30 – Updated: 2025-07-09 03:30A vulnerability has been found in 9fans plan9port up to 9da5b44 and classified as problematic. Affected by this vulnerability is the function value_decode in the library src/libsec/port/x509.c. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The identifier of the patch is deae8939583d83fd798fca97665e0e94656c3ee8. It is recommended to apply a patch to fix this issue.
{
"affected": [],
"aliases": [
"CVE-2025-7209"
],
"database_specific": {
"cwe_ids": [
"CWE-404",
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-09T01:15:50Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been found in 9fans plan9port up to 9da5b44 and classified as problematic. Affected by this vulnerability is the function value_decode in the library src/libsec/port/x509.c. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The identifier of the patch is deae8939583d83fd798fca97665e0e94656c3ee8. It is recommended to apply a patch to fix this issue.",
"id": "GHSA-v25m-v785-g666",
"modified": "2025-07-09T03:30:23Z",
"published": "2025-07-09T03:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7209"
},
{
"type": "WEB",
"url": "https://github.com/9fans/plan9port/issues/711"
},
{
"type": "WEB",
"url": "https://github.com/9fans/plan9port/issues/711#issuecomment-2819905220"
},
{
"type": "WEB",
"url": "https://git.9front.org/plan9front/plan9front/deae8939583d83fd798fca97665e0e94656c3ee8/commit.html"
},
{
"type": "WEB",
"url": "https://github.com/user-attachments/files/19698361/plan9port_crash_2.txt"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.315157"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.315157"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.607685"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-V285-5C63-6RPH
Vulnerability from github – Published: 2024-11-12 18:30 – Updated: 2024-11-12 18:30A null pointer dereference in Ivanti Avalanche before 6.4.6 allows a remote unauthenticated attacker to cause a denial of service.
{
"affected": [],
"aliases": [
"CVE-2024-50318"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-12T16:15:23Z",
"severity": "HIGH"
},
"details": "A null pointer dereference in Ivanti Avalanche before 6.4.6 allows a remote unauthenticated attacker to cause a denial of service.",
"id": "GHSA-v285-5c63-6rph",
"modified": "2024-11-12T18:30:56Z",
"published": "2024-11-12T18:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50318"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Avalanche-Multiple-CVEs-Q4-2024-Release"
}
],
"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"
}
]
}
GHSA-V2CH-C8V8-FGR7
Vulnerability from github – Published: 2025-08-29 16:24 – Updated: 2025-08-29 16:24Sending AWS chunk data with no Content-Length HTTP header causes the panic, every time.
Reproduction
Setup versity server running on port 7071, no SSL (for ease of packet tracing with tshark). Problem can be reproduced with or without SSL on the versity end.
Use nginx to reverse proxy on port 7070. This does have to be SSL enabled for the repro to occur. nginx config:
upstream tony_versity {
server 127.0.0.1:7071;
keepalive 15;
}
server {
listen 7070 ssl ;
access_log /var/log/nginx/tony_versity_proxy.access.log;
error_log /var/log/nginx/tony_versity_proxy.error.log;
# Allow any size file to be uploaded.
client_max_body_size 0;
# Allow special characters in headers
ignore_invalid_headers off;
# Disable buffering
proxy_buffering off;
proxy_request_buffering off;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
ssl_certificate "/WS/TEMP/lh.crt";
ssl_certificate_key "/WS/TEMP/lh.key";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.2 TLSv1.3;
location / {
allow all;
proxy_pass http://127.0.0.1:7071;
proxy_http_version 1.1;
proxy_read_timeout 120;
proxy_connect_timeout 300;
# Set headers
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Transfer-Encoding "";
# CORS headers
add_header 'Access-Control-Allow-Origin' '*' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Headers' 'Authorization,Accept,ETag,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range' always;
add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH' always;
add_header 'Access-Control-Expose-Headers' 'ETag, Content-Length, Content-Range' always;
# Optional security headers
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options DENY always;
add_header Referrer-Policy no-referrer always;
# Preflight (OPTIONS) handler
if ($request_method = OPTIONS) {
add_header Access-Control-Allow-Origin '*' always;
add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS, PUT, DELETE, PATCH' always;
add_header Access-Control-Allow-Headers 'Authorization,Accept,ETag,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range' always;
add_header Access-Control-Expose-Headers 'ETag, Content-Length, Content-Range' always;
add_header Content-Type text/plain;
add_header Content-Length 0;
return 204;
}
}
}
Use aws s3 cp to copy a large file (one that will trigger multipart upload) into versity via the nginx proxy on port 7070. AWS CLI must be version 2 for the repro to occur. Connecting directly to versity on port 7070 does not trigger the repro.
Initial crash analysis
The versity server enters a panic exception in function HashReader (csum-reader.go). The panic is due to a null value in the field r which should be a pointer to an io.Reader.
The reason this field is blank goes back to code in the fasthttp library, ContinueReadBodyStream. This function exits prematurely if the incoming request ContentLength field is set to -2, and therefore does not set up an io.Reader in the request context structure.
-2 is not a valid content-length for an HTTP message, it is a special value used internally by the fasthttp module. (Unfortunately the author hard coded the value rather than using a meaningful macro, which would have aided the understanding here. )
The reason for the -2 can be found in function parseHeaders(headers.go in fasthttp). The header struct content length is set to -2 at the start of the function, and will be overwritten if an HTTP content-length header is encountered during the parsing. If no such header is present in the request, it stays as -2 with the later result of skipping the creation of an io.Reader. Seems reasonable - no content, no need for a reader? (Note that the presence of content-length triggers body reader creation even if the value is 0.) The fasthttp code replaces the illegal -2 value with 0 before passing the request up to Versity.
So the pathway of this crash is receiving a request with no content-length, which means no body reader is set in the request context structure, but Versity tries to read anyway in the hash routines.
This pathology was confirmed by artificially creating a content-length on all incoming packets that didn’t have one, the outcome being that this panic did not occur, although the overall upload still reported failure (I didn’t go into exactly why as the point had been proven).
Further Analysis
The question becomes why there is no HTTP content-length header in this request. The answer to this is that the large transfer is being done using AWS chunking. Wireshark shows the packet structure. There is an initial POST request with content-length zero: Hypertext Transfer Protocol
POST /ttt/f2?uploads HTTP/1.1\r\n
Host: 127.0.0.1:7070\r\n
X-Real-IP: 127.0.0.1\r\n
X-Forwarded-For: 127.0.0.1\r\n
X-Forwarded-Proto: https\r\n
Connection: close\r\n
Content-Length: 0\r\n
Accept-Encoding: identity\r\n
x-amz-checksum-algorithm: CRC64NVME\r\n
[truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/E,Z,N,G,b cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#off
X-Amz-Date: 20250718T105915Z\r\n
X-Amz-Content-SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\r\n
[truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-checksum-algorithm;x-amz-content-sha256;x-amz-date, Signature=cd9f6a85ae2dd964aa44274d7d0642c51f8b32584
\r\n
[Full request URI: http://127.0.0.1:7070/ttt/f2?uploads]
[HTTP request 1/1]
[Response in frame: 6]
.. followed soon after by a PUT request with ‘content-encdoding: aws-chunked’. According to the AWS documentation, this encoding is used when the size of the upload is not known in advance, and a content-length header is expressly forbidden. AWS supplies other headers with size information, but these are not recognised by fasthttp. Hypertext Transfer Protocol
PUT /ttt/f2?uploadId=7170abfd-e29a-40fe-bd34-31b434cc1b6b&partNumber=1 HTTP/1.1\r\n
Host: 127.0.0.1:7070\r\n
X-Real-IP: 127.0.0.1\r\n
X-Forwarded-For: 127.0.0.1\r\n
X-Forwarded-Proto: https\r\n
Connection: close\r\n
Accept-Encoding: identity\r\n
x-amz-sdk-checksum-algorithm: CRC64NVME\r\n
[truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/E,Z,N,G,b,W cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#o
Content-Encoding: aws-chunked\r\n
X-Amz-Trailer: x-amz-checksum-crc64nvme\r\n
X-Amz-Decoded-Content-Length: 8388608\r\n
X-Amz-Date: 20250718T105915Z\r\n
X-Amz-Content-SHA256: STREAMING-UNSIGNED-PAYLOAD-TRAILER\r\n
[truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=content-encoding;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-sdk-checksum-algorithm;x-
\r\n
[Full request URI: http://127.0.0.1:7070/ttt/f2?uploadId=7170abfd-e29a-40fe-bd34-31b434cc1b6b&partNumber=1]
[HTTP request 1/1]
The initial response to the first POST request appears to be identical in both the direct and via nginx traces: DIRECT: Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Server: VERSITYGW\r\n
Date: Fri, 18 Jul 2025 11:01:02 GMT\r\n
Content-Type: application/xml\r\n
Content-Length: 240\r\n
X-Amz-Checksum-Algorithm: CRC64NVME\r\n
Connection: close\r\n
\r\n
[HTTP response 1/1]
[Time since request: 0.024200152 seconds]
[Request in frame: 4]
[Request URI: http://127.0.0.1:7071/ttt/f2?uploads]
File Data: 240 bytes
VIA NGINX PROXY: Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Server: VERSITYGW\r\n
Date: Fri, 18 Jul 2025 10:59:15 GMT\r\n
Content-Type: application/xml\r\n
Content-Length: 240\r\n
X-Amz-Checksum-Algorithm: CRC64NVME\r\n
Connection: close\r\n
\r\n
[HTTP response 1/1]
[Time since request: 0.024228406 seconds]
[Request in frame: 4]
[Request URI: http://127.0.0.1:7070/ttt/f2?uploads]
File Data: 240 bytes
What is yet to know
Wireshark traces show that the exact same AWS command results in a different upload pattern when connecting directly to Versity (with or without SSL) rather than going through nginx. There is a similar initial POST but followed by a stream of raw TCP with ‘100 - Continue’ responses from the server. There is no PUT request with content-encoding aws-chunked: Hypertext Transfer Protocol
POST /ttt/f2?uploads HTTP/1.1\r\n
Host: 127.0.0.1:7071\r\n
Accept-Encoding: identity\r\n
x-amz-checksum-algorithm: CRC64NVME\r\n
[truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/b,G,Z,N,E cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#off
X-Amz-Date: 20250718T110102Z\r\n
X-Amz-Content-SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\r\n
[truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-checksum-algorithm;x-amz-content-sha256;x-amz-date, Signature=925d2f18f7f88ab7826ae7faf61f95b17033f5e19
Content-Length: 0\r\n
\r\n
[Full request URI: http://127.0.0.1:7071/ttt/f2?uploads]
[HTTP request 1/1]
[Response in frame: 6]
It is unclear why AWS switches to the chunked mode when connecting through nginx. It is possible that changes to the nginx config could work around this, however the Versity behaviour remains a problem. At the very least this is a potential DDOS vulnerability. There is no structured exception handling in Versity at all and no defensive coding such as verifying callbacks are non-null before attempting to use them.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/versity/versitygw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-29T16:24:12Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Sending AWS chunk data with no Content-Length HTTP header causes the panic, every time. \n\n### Reproduction\n\nSetup versity server running on port 7071, no SSL (for ease of packet tracing with tshark). Problem can be reproduced with or without SSL on the versity end. \n\nUse nginx to reverse proxy on port 7070. This does have to be SSL enabled for the repro to occur. nginx config: \n\n```\nupstream tony_versity {\n server 127.0.0.1:7071;\n keepalive 15;\n}\n\nserver {\n listen 7070 ssl ;\n access_log /var/log/nginx/tony_versity_proxy.access.log;\n error_log /var/log/nginx/tony_versity_proxy.error.log;\n\n # Allow any size file to be uploaded.\n client_max_body_size 0;\n # Allow special characters in headers\n ignore_invalid_headers off;\n # Disable buffering\n proxy_buffering off;\n proxy_request_buffering off;\n\n # Load configuration files for the default server block.\n include /etc/nginx/default.d/*.conf;\n\n ssl_certificate \"/WS/TEMP/lh.crt\";\n ssl_certificate_key \"/WS/TEMP/lh.key\";\n ssl_session_cache shared:SSL:1m;\n ssl_session_timeout 10m;\n ssl_ciphers HIGH:!aNULL:!MD5;\n ssl_prefer_server_ciphers on;\n ssl_protocols TLSv1.2 TLSv1.3;\n\n location / {\n allow all;\n proxy_pass http://127.0.0.1:7071;\n proxy_http_version 1.1;\n proxy_read_timeout 120;\n proxy_connect_timeout 300;\n\n # Set headers\n proxy_set_header Host $http_host;\n proxy_set_header X-Real-IP $remote_addr;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_set_header X-Forwarded-Proto $scheme;\n proxy_set_header Transfer-Encoding \"\";\n\n # CORS headers\n add_header \u0027Access-Control-Allow-Origin\u0027 \u0027*\u0027 always;\n add_header \u0027Access-Control-Allow-Credentials\u0027 \u0027true\u0027 always;\n add_header \u0027Access-Control-Allow-Headers\u0027 \u0027Authorization,Accept,ETag,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range\u0027 always;\n add_header \u0027Access-Control-Allow-Methods\u0027 \u0027GET,POST,OPTIONS,PUT,DELETE,PATCH\u0027 always;\n add_header \u0027Access-Control-Expose-Headers\u0027 \u0027ETag, Content-Length, Content-Range\u0027 always;\n\n # Optional security headers\n add_header X-Content-Type-Options nosniff always;\n add_header X-Frame-Options DENY always;\n add_header Referrer-Policy no-referrer always;\n\n # Preflight (OPTIONS) handler\n if ($request_method = OPTIONS) {\n add_header Access-Control-Allow-Origin \u0027*\u0027 always;\n add_header Access-Control-Allow-Methods \u0027GET, POST, OPTIONS, PUT, DELETE, PATCH\u0027 always;\n add_header Access-Control-Allow-Headers \u0027Authorization,Accept,ETag,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range\u0027 always;\n add_header Access-Control-Expose-Headers \u0027ETag, Content-Length, Content-Range\u0027 always;\n add_header Content-Type text/plain;\n add_header Content-Length 0;\n return 204;\n }\n }\n}\n```\n\nUse aws s3 cp to copy a large file (one that will trigger multipart upload) into versity via the nginx proxy on port 7070. AWS CLI must be version 2 for the repro to occur. Connecting directly to versity on port 7070 does not trigger the repro.\n\n \n### Initial crash analysis\n\nThe versity server enters a panic exception in function `HashReader` (csum-reader.go). The panic is due to a null value in the field r which should be a pointer to an io.Reader. \n\nThe reason this field is blank goes back to code in the `fasthttp` library, `ContinueReadBodyStream`. This function exits prematurely if the incoming request `ContentLength` field is set to `-2`, and therefore does not set up an io.Reader in the request context structure. \n\n`-2` is not a valid content-length for an HTTP message, it is a special value used internally by the `fasthttp` module. (Unfortunately the author hard coded the value rather than using a meaningful macro, which would have aided the understanding here. )\n\nThe reason for the `-2` can be found in function `parseHeaders`(headers.go in fasthttp). The header struct content length is set to `-2` at the start of the function, and will be overwritten if an HTTP content-length header is encountered during the parsing. If no such header is present in the request, it stays as `-2` with the later result of skipping the creation of an io.Reader. Seems reasonable - no content, no need for a reader? (Note that the presence of content-length triggers body reader creation even if the value is 0.) The fasthttp code replaces the illegal `-2` value with `0` before passing the request up to Versity. \n\nSo the pathway of this crash is receiving a request with no content-length, which means no body reader is set in the request context structure, but Versity tries to read anyway in the hash routines. \n\nThis pathology was confirmed by artificially creating a content-length on all incoming packets that didn\u2019t have one, the outcome being that this panic did not occur, although the overall upload still reported failure (I didn\u2019t go into exactly why as the point had been proven).\n\n \n### Further Analysis\n\nThe question becomes why there is no HTTP content-length header in this request. The answer to this is that the large transfer is being done using AWS chunking. Wireshark shows the packet structure. There is an initial POST request with content-length zero:\nHypertext Transfer Protocol\n```\n POST /ttt/f2?uploads HTTP/1.1\\r\\n\n Host: 127.0.0.1:7070\\r\\n\n X-Real-IP: 127.0.0.1\\r\\n\n X-Forwarded-For: 127.0.0.1\\r\\n\n X-Forwarded-Proto: https\\r\\n\n Connection: close\\r\\n\n Content-Length: 0\\r\\n\n Accept-Encoding: identity\\r\\n\n x-amz-checksum-algorithm: CRC64NVME\\r\\n\n [truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/E,Z,N,G,b cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#off\n X-Amz-Date: 20250718T105915Z\\r\\n\n X-Amz-Content-SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\\r\\n\n [truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-checksum-algorithm;x-amz-content-sha256;x-amz-date, Signature=cd9f6a85ae2dd964aa44274d7d0642c51f8b32584\n \\r\\n\n [Full request URI: http://127.0.0.1:7070/ttt/f2?uploads]\n [HTTP request 1/1]\n [Response in frame: 6]\n```\n.. followed soon after by a PUT request with \u2018content-encdoding: aws-chunked\u2019. According to the AWS documentation, this encoding is used when the size of the upload is not known in advance, and a content-length header is expressly forbidden. AWS supplies other headers with size information, but these are not recognised by fasthttp.\nHypertext Transfer Protocol\n```\n PUT /ttt/f2?uploadId=7170abfd-e29a-40fe-bd34-31b434cc1b6b\u0026partNumber=1 HTTP/1.1\\r\\n\n Host: 127.0.0.1:7070\\r\\n\n X-Real-IP: 127.0.0.1\\r\\n\n X-Forwarded-For: 127.0.0.1\\r\\n\n X-Forwarded-Proto: https\\r\\n\n Connection: close\\r\\n\n Accept-Encoding: identity\\r\\n\n x-amz-sdk-checksum-algorithm: CRC64NVME\\r\\n\n [truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/E,Z,N,G,b,W cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#o\n Content-Encoding: aws-chunked\\r\\n\n X-Amz-Trailer: x-amz-checksum-crc64nvme\\r\\n\n X-Amz-Decoded-Content-Length: 8388608\\r\\n\n X-Amz-Date: 20250718T105915Z\\r\\n\n X-Amz-Content-SHA256: STREAMING-UNSIGNED-PAYLOAD-TRAILER\\r\\n\n [truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=content-encoding;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-sdk-checksum-algorithm;x-\n \\r\\n\n [Full request URI: http://127.0.0.1:7070/ttt/f2?uploadId=7170abfd-e29a-40fe-bd34-31b434cc1b6b\u0026partNumber=1]\n [HTTP request 1/1]\n```\n \n\nThe initial response to the first POST request appears to be identical in both the direct and via nginx traces:\nDIRECT:\nHypertext Transfer Protocol\n```\n HTTP/1.1 200 OK\\r\\n\n Server: VERSITYGW\\r\\n\n Date: Fri, 18 Jul 2025 11:01:02 GMT\\r\\n\n Content-Type: application/xml\\r\\n\n Content-Length: 240\\r\\n\n X-Amz-Checksum-Algorithm: CRC64NVME\\r\\n\n Connection: close\\r\\n\n \\r\\n\n [HTTP response 1/1]\n [Time since request: 0.024200152 seconds]\n [Request in frame: 4]\n [Request URI: http://127.0.0.1:7071/ttt/f2?uploads]\n File Data: 240 bytes\n```\n \nVIA NGINX PROXY:\nHypertext Transfer Protocol\n```\n HTTP/1.1 200 OK\\r\\n\n Server: VERSITYGW\\r\\n\n Date: Fri, 18 Jul 2025 10:59:15 GMT\\r\\n\n Content-Type: application/xml\\r\\n\n Content-Length: 240\\r\\n\n X-Amz-Checksum-Algorithm: CRC64NVME\\r\\n\n Connection: close\\r\\n\n \\r\\n\n [HTTP response 1/1]\n [Time since request: 0.024228406 seconds]\n [Request in frame: 4]\n [Request URI: http://127.0.0.1:7070/ttt/f2?uploads]\n File Data: 240 bytes\n```\n### What is yet to know\n\nWireshark traces show that the exact same AWS command results in a different upload pattern when connecting directly to Versity (with or without SSL) rather than going through nginx. There is a similar initial POST but followed by a stream of raw TCP with \u2018100 - Continue\u2019 responses from the server. There is no PUT request with content-encoding aws-chunked:\nHypertext Transfer Protocol\n```\n POST /ttt/f2?uploads HTTP/1.1\\r\\n\n Host: 127.0.0.1:7071\\r\\n\n Accept-Encoding: identity\\r\\n\n x-amz-checksum-algorithm: CRC64NVME\\r\\n\n [truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/b,G,Z,N,E cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#off\n X-Amz-Date: 20250718T110102Z\\r\\n\n X-Amz-Content-SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\\r\\n\n [truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-checksum-algorithm;x-amz-content-sha256;x-amz-date, Signature=925d2f18f7f88ab7826ae7faf61f95b17033f5e19\n Content-Length: 0\\r\\n\n \\r\\n\n [Full request URI: http://127.0.0.1:7071/ttt/f2?uploads]\n [HTTP request 1/1]\n [Response in frame: 6]\n```\nIt is unclear why AWS switches to the chunked mode when connecting through nginx. It is possible that changes to the nginx config could work around this, however the Versity behaviour remains a problem. At the very least this is a potential DDOS vulnerability. There is no structured exception handling in Versity at all and no defensive coding such as verifying callbacks are non-null before attempting to use them.",
"id": "GHSA-v2ch-c8v8-fgr7",
"modified": "2025-08-29T16:24:12Z",
"published": "2025-08-29T16:24:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/versity/versitygw/security/advisories/GHSA-v2ch-c8v8-fgr7"
},
{
"type": "WEB",
"url": "https://github.com/versity/versitygw/issues/1418"
},
{
"type": "WEB",
"url": "https://github.com/versity/versitygw/commit/0972af078325ab5c6acd37abffe6bea345ac7db0"
},
{
"type": "PACKAGE",
"url": "https://github.com/versity/versitygw"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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/E:P",
"type": "CVSS_V4"
}
],
"summary": "Versity panic induced by AWS chunked data sent to port"
}
GHSA-V2GM-5JQW-X4QC
Vulnerability from github – Published: 2025-05-03 00:30 – Updated: 2025-05-12 15:30ffmpeg 7.1 is vulnerable to Null Pointer Dereference in function iamf_read_header in /libavformat/iamfdec.c.
{
"affected": [],
"aliases": [
"CVE-2024-55069"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-02T22:15:16Z",
"severity": "MODERATE"
},
"details": "ffmpeg 7.1 is vulnerable to Null Pointer Dereference in function iamf_read_header in /libavformat/iamfdec.c.",
"id": "GHSA-v2gm-5jqw-x4qc",
"modified": "2025-05-12T15:30:40Z",
"published": "2025-05-03T00:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55069"
},
{
"type": "WEB",
"url": "https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/4cc1495aca45445181a107a682c32cfe31459929"
},
{
"type": "WEB",
"url": "https://trac.ffmpeg.org/ticket/11326"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V2J3-MR9J-GQ5X
Vulnerability from github – Published: 2022-09-17 00:00 – Updated: 2022-09-22 00:00A NULL pointer dereference issue in the TEE_MACCompareFinal function in Samsung mTower through 0.3.0 allows a trusted application to trigger a Denial of Service (DoS) by invoking the function TEE_MACCompareFinal with a NULL pointer for the parameter operation.
{
"affected": [],
"aliases": [
"CVE-2022-40759"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-16T22:15:00Z",
"severity": "HIGH"
},
"details": "A NULL pointer dereference issue in the TEE_MACCompareFinal function in Samsung mTower through 0.3.0 allows a trusted application to trigger a Denial of Service (DoS) by invoking the function TEE_MACCompareFinal with a NULL pointer for the parameter operation.",
"id": "GHSA-v2j3-mr9j-gq5x",
"modified": "2022-09-22T00:00:23Z",
"published": "2022-09-17T00:00:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40759"
},
{
"type": "WEB",
"url": "https://github.com/Samsung/mTower/issues/80"
},
{
"type": "WEB",
"url": "https://github.com/Samsung/mTower/blob/efd36709306a9afcca5b4782499d01be0c7a02a5/tee/lib/libutee/tee_api_operations.c#L1249"
}
],
"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"
}
]
}
GHSA-V2M4-F87M-9VV4
Vulnerability from github – Published: 2025-03-18 21:31 – Updated: 2025-03-18 21:31In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix the svc_deferred_event trace class
Fix a NULL deref crash that occurs when an svc_rqst is deferred while the sunrpc tracing subsystem is enabled. svc_revisit() sets dr->xprt to NULL, so it can't be relied upon in the tracepoint to provide the remote's address.
Unfortunately we can't revert the "svc_deferred_class" hunk in commit ece200ddd54b ("sunrpc: Save remote presentation address in svc_xprt for trace events") because there is now a specific check of event format specifiers for unsafe dereferences. The warning that check emits is:
event svc_defer_recv has unsafe dereference of argument 1
A "%pISpc" format specifier with a "struct sockaddr *" is indeed flagged by this check.
Instead, take the brute-force approach used by the svcrdma_qp_error tracepoint. Convert the dr::addr field into a presentation address in the TP_fast_assign() arm of the trace event, and store that as a string. This fix can be backported to -stable kernels.
In the meantime, commit c6ced22997ad ("tracing: Update print fmt check to handle new __get_sockaddr() macro") is now in v5.18, so this wonky fix can be replaced with __sockaddr() and friends properly during the v5.19 merge window.
{
"affected": [],
"aliases": [
"CVE-2022-49065"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Fix the svc_deferred_event trace class\n\nFix a NULL deref crash that occurs when an svc_rqst is deferred\nwhile the sunrpc tracing subsystem is enabled. svc_revisit() sets\ndr-\u003exprt to NULL, so it can\u0027t be relied upon in the tracepoint to\nprovide the remote\u0027s address.\n\nUnfortunately we can\u0027t revert the \"svc_deferred_class\" hunk in\ncommit ece200ddd54b (\"sunrpc: Save remote presentation address in\nsvc_xprt for trace events\") because there is now a specific check\nof event format specifiers for unsafe dereferences. The warning\nthat check emits is:\n\n event svc_defer_recv has unsafe dereference of argument 1\n\nA \"%pISpc\" format specifier with a \"struct sockaddr *\" is indeed\nflagged by this check.\n\nInstead, take the brute-force approach used by the svcrdma_qp_error\ntracepoint. Convert the dr::addr field into a presentation address\nin the TP_fast_assign() arm of the trace event, and store that as\na string. This fix can be backported to -stable kernels.\n\nIn the meantime, commit c6ced22997ad (\"tracing: Update print fmt\ncheck to handle new __get_sockaddr() macro\") is now in v5.18, so\nthis wonky fix can be replaced with __sockaddr() and friends\nproperly during the v5.19 merge window.",
"id": "GHSA-v2m4-f87m-9vv4",
"modified": "2025-03-18T21:31:59Z",
"published": "2025-03-18T21:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49065"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d5004451ab2218eab94a30e1841462c9316ba19"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/726ae7300fcc25fefa46d188cc07eb16dc908f9e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85ee17ca21cf92989e8c923e3ea4514c291e9d38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2456f470eea3bd06574d988bf6089e7c3f4c5cc"
}
],
"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"
}
]
}
Mitigation MIT-56
For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished [REF-1484].
Mitigation
Select a programming language that is not susceptible to these issues.
Mitigation
Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
Mitigation
Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.
Mitigation
Explicitly initialize all variables and other data stores, either during declaration or just before the first usage.
No CAPEC attack patterns related to this CWE.