<This issue is referenced from a **SPAM**/nonsense CVE with no explanation and no good reason. Ignore it as there is no actual vulnerability here>

[x1280]

[Dreamsorcerer]

The code appears to be catching a HttpProcessingError exception:
https://github.com/google/oss-fuzz/blob/master/projects/aiohttp/fuzz_http_parser.py#L42

So, maybe our parser should consider catching and rethrowing this exception.

[webknjaz]

Uploading crash.zip…

This is a link to the current issue, not an actual attachment. Do you have any proof that this is actually a problem?

Denial of service

Why do you think it's expected?

ValueError: Invalid IPv6 URL
Traceback (most recent call last):
  File "fuzz_http_parser.py", line 32, in TestOneInput
  File "aiohttp/_http_parser.pyx", line 551, in aiohttp._http_parser.HttpParser.feed_data
  File "aiohttp/_http_parser.pyx", line 701, in aiohttp._http_parser.cb_on_header_field
  File "aiohttp/_http_parser.pyx", line 627, in aiohttp._http_parser.HttpRequestParser._on_status_complete
  File "yarl/_url.py", line 151, in __new__
  File "urllib/parse.py", line 464, in urlsplit

This only demonstrates a traceback coming from stdlib (urllib) and yarl. So what's an actual complaint in the aiohttp-land?

[giorgiop]

FYI https://security.snyk.io/vuln/SNYK-PYTHON-AIOHTTP-2934978

[Rongronggg9]

Now everyone gets informed that there is a vulnerability "waiting for a PoC", but everyone just can't see any evidence indicating that aiohttp is vulnerable.

CVE-2022-33124

** DISPUTED ** AIOHTTP 3.8.1 can report a "ValueError: Invalid IPv6 URL" outcome, which can lead to a Denial of Service (DoS). NOTE: multiple third parties dispute this issue because there is no example of a context in which denial of service would occur, and many common contexts have exception handing in the calling application.

Without any PoC, if only raising an exception can be considered to be a DoS vulnerability instead of a bug or expected behavior, well, should CVE-ID be 64bit long?

aiohttp v3.8.1 was discovered to contain an invalid IPv6 URL which can lead to a Denial of Service (DoS).

I can't say anything but lol

---

So, please show your "example of a context in which denial of service would occur". Don't make unnecessary misunderstandings happen (already happened if it does not be a vulnerability since a CVE-ID has been registered).

[webknjaz]

$ python -m pip show aiohttp
latest

I also wonder what the latest means in this context. Since it's clearly not an output that the above command produces but something user-invented, it's hard to judge what it refers to. Is it the latest version published to PyPI? Or is it something built from source. (I think it's the latter because of how the paths show up in the traceback).
If it's been built from the source, there's more questions to answer on how it's been built and whether it was built from the HEAD of this repo's default branch or maybe from a minor version branch HEAD. Without this, it's hard to guess what exactly this issue is implying even.

[webknjaz]

I can't say anything but lol

Exactly what I was thinking. Note that there's some discussions along the same lines @ #6801.

[woodruffw]

For pip-audit users, you can temporarily ignore this disputed vulnerability using the --ignore-vuln flag:

$ pip-audit --ignore-vuln GHSA-rwqr-c348-m5wr

[DavidKorczynski]

I'm the author of the fuzzers in the OSS-Fuzz repo (https://github.com/google/oss-fuzz/tree/master/projects/aiohttp). Sorry to see this mess -- the CVE filing or security filing does not come from OSS-Fuzz and am not sure who files them. This has previously happened, e.g. see this OSS-Fuzz issue which deals with unknown CVE filings google/oss-fuzz#7146.

In this context, I would be happy to develop the fuzzing suite into aiohttp and submit it all upstream so you can review and ensure it matches your threat model, i.e. I would be happy to revive this PR #5320

Again, many apologies that this false security filing happened.

[tooptoop4]

yo aqua/cve: update ur db and processes, dis issue got me f#*d up

[webknjaz]

I would be happy to revive this PR #5320

Yeah, that could be useful but in order to proceed, it really has to be integrated into the pytest setup we've got first, as I mentioned earlier: #5320 (review). Running the fuzzers could be controlled by pytest markers, for example.