Repository navigation
bpo-41004: Resolve hash collisions for IPv4Interface and IPv6Interface - #21033
Merged
ericvsmith merged 6 commits intoJun 29, 2020
Merged
ericvsmith merged 6 commits into
ericvsmith merged 6 commits into
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation
Copy link
Copy Markdown
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA). CLA MissingOur records indicate the following people have not signed the CLA: For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. If you have recently signed the CLA, please wait at least one business day You can check yourself to see if the CLA has been received. Thanks again for the contribution, we look forward to reviewing it! |
Sorry, something went wrong.
rhettinger
approved these changes
Jun 28, 2020
ericvsmith
requested changes
Jun 28, 2020
Comment thread
Lib/test/test_ipaddress.py
Outdated
Comment thread
Lib/test/test_ipaddress.py
Outdated
Comment thread
Misc/NEWS.d/next/Security/2020-06-21-19-01-01.bpo-41004.P6i7Nj.rst
Outdated
Comment thread
Misc/NEWS.d/next/Security/2020-06-21-19-01-01.bpo-41004.P6i7Nj.rst
Outdated
Copy link
Copy Markdown
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request. And if you don't make the requested changes, you will be poked with soft cushions! |
Sorry, something went wrong.
ericvsmith
requested changes
Jun 29, 2020
Comment thread
Lib/test/test_ipaddress.py
Outdated
Comment thread
Lib/test/test_ipaddress.py
Outdated
Copy link
Copy Markdown
Contributor
|
Thanks @rvteja92 for the PR, and @ericvsmith for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8, 3.9. |
Sorry, something went wrong.
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this pull request
Jun 29, 2020
pythonGH-21033) The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation (cherry picked from commit b30ee26) Co-authored-by: Ravi Teja P <rvteja92@gmail.com>
Copy link
Copy Markdown
|
GH-21220 is a backport of this pull request to the 3.9 branch. |
Sorry, something went wrong.
Copy link
Copy Markdown
|
GH-21221 is a backport of this pull request to the 3.8 branch. |
Sorry, something went wrong.
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this pull request
Jun 29, 2020
pythonGH-21033) The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation (cherry picked from commit b30ee26) Co-authored-by: Ravi Teja P <rvteja92@gmail.com>
miss-islington
added a commit
that referenced
this pull request
Jun 29, 2020
GH-21033) The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation (cherry picked from commit b30ee26) Co-authored-by: Ravi Teja P <rvteja92@gmail.com>
miss-islington
added a commit
that referenced
this pull request
Jun 29, 2020
GH-21033) The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation (cherry picked from commit b30ee26) Co-authored-by: Ravi Teja P <rvteja92@gmail.com>
tapakund
added a commit
to tapakund/cpython
that referenced
this pull request
Jun 30, 2020
…terface (pythonGH-21033) The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation (cherry picked from commit b30ee26) Co-authored-by: Ravi Teja P <rvteja92@gmail.com> Signed-off-by: Tapas Kundu <tkundu@vmware.com>
tapakund
added a commit
to tapakund/cpython
that referenced
this pull request
Jun 30, 2020
…terface (pythonGH-21033) The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation (cherry picked from commit b30ee26) Co-authored-by: Ravi Teja P <rvteja92@gmail.com> Signed-off-by: Tapas Kundu <tkundu@vmware.com>
tapakund
added a commit
to tapakund/cpython
that referenced
this pull request
Jun 30, 2020
…terface (pythonGH-21033) The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation (cherry picked from commit b30ee26) Co-authored-by: Ravi Teja P <rvteja92@gmail.com> Signed-off-by: Tapas Kundu <tkundu@vmware.com>
ned-deily
pushed a commit
that referenced
this pull request
Jun 30, 2020
…terface (GH-21033) (GH-21231) CVE-2020-14422 The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation (cherry picked from commit b30ee26) Co-authored-by: Ravi Teja P <rvteja92@gmail.com> Signed-off-by: Tapas Kundu <tkundu@vmware.com>
ned-deily
pushed a commit
that referenced
this pull request
Jun 30, 2020
…terface (GH-21033) (GH-21232) CVE-2020-14422 The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation (cherry picked from commit b30ee26) Co-authored-by: Ravi Teja P <rvteja92@gmail.com> Signed-off-by: Tapas Kundu <tkundu@vmware.com>
Copy link
Copy Markdown
⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️Hi! The buildbot PPC64LE Fedora Stable LTO + PGO 3.7 has failed when building commit b98e779. What do you need to do:
You can take a look at the buildbot page here: https://buildbot.python.org/all/#builders/429/builds/130 Summary of the results of the build (if available): Click to see traceback logsremote: Enumerating objects: 598
remote: Enumerating objects: 423, done.
remote: Counting objects: 0% (1/423)
remote: Counting objects: 1% (5/423)
remote: Counting objects: 2% (9/423)
remote: Counting objects: 3% (13/423)
remote: Counting objects: 4% (17/423)
remote: Counting objects: 5% (22/423)
remote: Counting objects: 6% (26/423)
remote: Counting objects: 7% (30/423)
remote: Counting objects: 8% (34/423)
remote: Counting objects: 9% (39/423)
remote: Counting objects: 10% (43/423)
remote: Counting objects: 11% (47/423)
remote: Counting objects: 12% (51/423)
remote: Counting objects: 13% (55/423)
remote: Counting objects: 14% (60/423)
remote: Counting objects: 15% (64/423)
remote: Counting objects: 16% (68/423)
remote: Counting objects: 17% (72/423)
remote: Counting objects: 18% (77/423)
remote: Counting objects: 19% (81/423)
remote: Counting objects: 20% (85/423)
remote: Counting objects: 21% (89/423)
remote: Counting objects: 22% (94/423)
remote: Counting objects: 23% (98/423)
remote: Counting objects: 24% (102/423)
remote: Counting objects: 25% (106/423)
remote: Counting objects: 26% (110/423)
remote: Counting objects: 27% (115/423)
remote: Counting objects: 28% (119/423)
remote: Counting objects: 29% (123/423)
remote: Counting objects: 30% (127/423)
remote: Counting objects: 31% (132/423)
remote: Counting objects: 32% (136/423)
remote: Counting objects: 33% (140/423)
remote: Counting objects: 34% (144/423)
remote: Counting objects: 35% (149/423)
remote: Counting objects: 36% (153/423)
remote: Counting objects: 37% (157/423)
remote: Counting objects: 38% (161/423)
remote: Counting objects: 39% (165/423)
remote: Counting objects: 40% (170/423)
remote: Counting objects: 41% (174/423)
remote: Counting objects: 42% (178/423)
remote: Counting objects: 43% (182/423)
remote: Counting objects: 44% (187/423)
remote: Counting objects: 45% (191/423)
remote: Counting objects: 46% (195/423)
remote: Counting objects: 47% (199/423)
remote: Counting objects: 48% (204/423)
remote: Counting objects: 49% (208/423)
remote: Counting objects: 50% (212/423)
remote: Counting objects: 51% (216/423)
remote: Counting objects: 52% (220/423)
remote: Counting objects: 53% (225/423)
remote: Counting objects: 54% (229/423)
remote: Counting objects: 55% (233/423)
remote: Counting objects: 56% (237/423)
remote: Counting objects: 57% (242/423)
remote: Counting objects: 58% (246/423)
remote: Counting objects: 59% (250/423)
remote: Counting objects: 60% (254/423)
remote: Counting objects: 61% (259/423)
remote: Counting objects: 62% (263/423)
remote: Counting objects: 63% (267/423)
remote: Counting objects: 64% (271/423)
remote: Counting objects: 65% (275/423)
remote: Counting objects: 66% (280/423)
remote: Counting objects: 67% (284/423)
remote: Counting objects: 68% (288/423)
remote: Counting objects: 69% (292/423)
remote: Counting objects: 70% (297/423)
remote: Counting objects: 71% (301/423)
remote: Counting objects: 72% (305/423)
remote: Counting objects: 73% (309/423)
remote: Counting objects: 74% (314/423)
remote: Counting objects: 75% (318/423)
remote: Counting objects: 76% (322/423)
remote: Counting objects: 77% (326/423)
remote: Counting objects: 78% (330/423)
remote: Counting objects: 79% (335/423)
remote: Counting objects: 80% (339/423)
remote: Counting objects: 81% (343/423)
remote: Counting objects: 82% (347/423)
remote: Counting objects: 83% (352/423)
remote: Counting objects: 84% (356/423)
remote: Counting objects: 85% (360/423)
remote: Counting objects: 86% (364/423)
remote: Counting objects: 87% (369/423)
remote: Counting objects: 88% (373/423)
remote: Counting objects: 89% (377/423)
remote: Counting objects: 90% (381/423)
remote: Counting objects: 91% (385/423)
remote: Counting objects: 92% (390/423)
remote: Counting objects: 93% (394/423)
remote: Counting objects: 94% (398/423)
remote: Counting objects: 95% (402/423)
remote: Counting objects: 96% (407/423)
remote: Counting objects: 97% (411/423)
remote: Counting objects: 98% (415/423)
remote: Counting objects: 99% (419/423)
remote: Counting objects: 100% (423/423)
remote: Counting objects: 100% (423/423), done.
remote: Compressing objects: 33% (1/3)
remote: Compressing objects: 66% (2/3)
remote: Compressing objects: 100% (3/3)
remote: Compressing objects: 100% (3/3), done.
Receiving objects: 0% (1/1021)
Receiving objects: 1% (11/1021)
Receiving objects: 2% (21/1021)
Receiving objects: 3% (31/1021)
Receiving objects: 4% (41/1021)
Receiving objects: 5% (52/1021)
Receiving objects: 6% (62/1021)
Receiving objects: 7% (72/1021)
Receiving objects: 8% (82/1021)
Receiving objects: 9% (92/1021)
Receiving objects: 10% (103/1021)
Receiving objects: 11% (113/1021)
Receiving objects: 12% (123/1021)
Receiving objects: 13% (133/1021)
Receiving objects: 14% (143/1021)
Receiving objects: 15% (154/1021)
Receiving objects: 16% (164/1021)
Receiving objects: 17% (174/1021)
Receiving objects: 18% (184/1021)
Receiving objects: 19% (194/1021)
Receiving objects: 20% (205/1021)
Receiving objects: 21% (215/1021)
Receiving objects: 22% (225/1021)
Receiving objects: 23% (235/1021)
Receiving objects: 24% (246/1021)
Receiving objects: 25% (256/1021)
Receiving objects: 26% (266/1021)
Receiving objects: 27% (276/1021)
Receiving objects: 28% (286/1021)
Receiving objects: 29% (297/1021)
Receiving objects: 30% (307/1021)
Receiving objects: 31% (317/1021)
Receiving objects: 32% (327/1021)
Receiving objects: 33% (337/1021)
Receiving objects: 34% (348/1021)
Receiving objects: 35% (358/1021)
Receiving objects: 36% (368/1021)
Receiving objects: 37% (378/1021)
Receiving objects: 38% (388/1021)
Receiving objects: 39% (399/1021)
Receiving objects: 40% (409/1021)
Receiving objects: 41% (419/1021)
Receiving objects: 42% (429/1021)
Receiving objects: 43% (440/1021)
Receiving objects: 44% (450/1021)
Receiving objects: 45% (460/1021)
Receiving objects: 46% (470/1021)
Receiving objects: 47% (480/1021)
Receiving objects: 48% (491/1021)
Receiving objects: 49% (501/1021)
Receiving objects: 50% (511/1021)
Receiving objects: 51% (521/1021)
Receiving objects: 52% (531/1021)
Receiving objects: 53% (542/1021)
Receiving objects: 54% (552/1021)
Receiving objects: 55% (562/1021)
Receiving objects: 56% (572/1021)
Receiving objects: 57% (582/1021)
Receiving objects: 58% (593/1021)
Receiving objects: 59% (603/1021)
Receiving objects: 60% (613/1021)
Receiving objects: 61% (623/1021)
Receiving objects: 62% (634/1021)
Receiving objects: 63% (644/1021)
Receiving objects: 64% (654/1021)
Receiving objects: 65% (664/1021)
Receiving objects: 66% (674/1021)
Receiving objects: 67% (685/1021)
Receiving objects: 68% (695/1021)
Receiving objects: 69% (705/1021)
Receiving objects: 70% (715/1021)
Receiving objects: 71% (725/1021)
Receiving objects: 72% (736/1021)
Receiving objects: 73% (746/1021)
Receiving objects: 74% (756/1021)
Receiving objects: 75% (766/1021)
Receiving objects: 76% (776/1021)
Receiving objects: 77% (787/1021)
Receiving objects: 78% (797/1021)
Receiving objects: 79% (807/1021)
Receiving objects: 80% (817/1021)
Receiving objects: 81% (828/1021)
Receiving objects: 82% (838/1021)
Receiving objects: 83% (848/1021)
Receiving objects: 84% (858/1021)
Receiving objects: 85% (868/1021)
Receiving objects: 86% (879/1021)
Receiving objects: 87% (889/1021)
Receiving objects: 88% (899/1021)
Receiving objects: 89% (909/1021)
Receiving objects: 90% (919/1021)
remote: Total 1021 (delta 420), reused 422 (delta 420), pack-reused 598
Receiving objects: 91% (930/1021)
Receiving objects: 92% (940/1021)
Receiving objects: 93% (950/1021)
Receiving objects: 94% (960/1021)
Receiving objects: 95% (970/1021)
Receiving objects: 96% (981/1021)
Receiving objects: 97% (991/1021)
Receiving objects: 98% (1001/1021)
Receiving objects: 99% (1011/1021)
Receiving objects: 100% (1021/1021)
Receiving objects: 100% (1021/1021), 434.20 KiB | 1.24 MiB/s, done.
Resolving deltas: 0% (0/740)
Resolving deltas: 3% (26/740)
Resolving deltas: 4% (33/740)
Resolving deltas: 5% (39/740)
Resolving deltas: 6% (46/740)
Resolving deltas: 10% (77/740)
Resolving deltas: 11% (87/740)
Resolving deltas: 12% (90/740)
Resolving deltas: 13% (97/740)
Resolving deltas: 14% (105/740)
Resolving deltas: 15% (115/740)
Resolving deltas: 16% (125/740)
Resolving deltas: 17% (129/740)
Resolving deltas: 20% (149/740)
Resolving deltas: 21% (161/740)
Resolving deltas: 22% (163/740)
Resolving deltas: 23% (176/740)
Resolving deltas: 24% (178/740)
Resolving deltas: 25% (185/740)
Resolving deltas: 26% (194/740)
Resolving deltas: 27% (200/740)
Resolving deltas: 28% (210/740)
Resolving deltas: 30% (222/740)
Resolving deltas: 31% (232/740)
Resolving deltas: 32% (239/740)
Resolving deltas: 33% (247/740)
Resolving deltas: 34% (257/740)
Resolving deltas: 35% (261/740)
Resolving deltas: 36% (268/740)
Resolving deltas: 37% (280/740)
Resolving deltas: 38% (283/740)
Resolving deltas: 39% (291/740)
Resolving deltas: 40% (296/740)
Resolving deltas: 41% (304/740)
Resolving deltas: 42% (311/740)
Resolving deltas: 43% (320/740)
Resolving deltas: 44% (326/740)
Resolving deltas: 45% (334/740)
Resolving deltas: 46% (341/740)
Resolving deltas: 47% (348/740)
Resolving deltas: 48% (356/740)
Resolving deltas: 49% (364/740)
Resolving deltas: 52% (387/740)
Resolving deltas: 53% (393/740)
Resolving deltas: 55% (408/740)
Resolving deltas: 56% (417/740)
Resolving deltas: 57% (423/740)
Resolving deltas: 58% (431/740)
Resolving deltas: 59% (441/740)
Resolving deltas: 61% (458/740)
Resolving deltas: 62% (460/740)
Resolving deltas: 63% (467/740)
Resolving deltas: 64% (476/740)
Resolving deltas: 65% (484/740)
Resolving deltas: 66% (489/740)
Resolving deltas: 67% (497/740)
Resolving deltas: 70% (520/740)
Resolving deltas: 71% (527/740)
Resolving deltas: 72% (536/740)
Resolving deltas: 73% (543/740)
Resolving deltas: 74% (549/740)
Resolving deltas: 75% (555/740)
Resolving deltas: 76% (564/740)
Resolving deltas: 77% (570/740)
Resolving deltas: 78% (578/740)
Resolving deltas: 79% (585/740)
Resolving deltas: 80% (592/740)
Resolving deltas: 81% (600/740)
Resolving deltas: 82% (607/740)
Resolving deltas: 83% (615/740)
Resolving deltas: 84% (622/740)
Resolving deltas: 85% (629/740)
Resolving deltas: 86% (637/740)
Resolving deltas: 87% (644/740)
Resolving deltas: 88% (653/740)
Resolving deltas: 89% (659/740)
Resolving deltas: 90% (666/740)
Resolving deltas: 91% (674/740)
Resolving deltas: 92% (681/740)
Resolving deltas: 93% (689/740)
Resolving deltas: 94% (696/740)
Resolving deltas: 95% (704/740)
Resolving deltas: 96% (711/740)
Resolving deltas: 97% (718/740)
Resolving deltas: 98% (726/740)
Resolving deltas: 98% (732/740)
Resolving deltas: 99% (733/740)
Resolving deltas: 100% (740/740)
Resolving deltas: 100% (740/740), completed with 217 local objects.
From https://github.com/python/cpython
* branch 3.7 -> FETCH_HEAD
* [new tag] v3.8.4rc1 -> v3.8.4rc1
Reset branch '3.7'
find: ‘build’: No such file or directory
find: ‘build’: No such file or directory
find: ‘build’: No such file or directory
find: ‘build’: No such file or directory
make[2]: [Makefile:1722: clean] Error 1 (ignored)
Objects/longobject.c: In function ‘_PyLong_Frexp’:
Objects/longobject.c:2826:33: warning: ‘x_digits[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
2826 | x_digits[0] |= 1;
| ^~
In file included from Python/ast.c:8:
Python/ast.c: In function ‘ast_for_stmt’:
./Include/node.h:34:29: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
34 | #define LINENO(n) ((n)->n_lineno)
| ~~~~^~~~~~~~~~~
In function ‘assemble_lnotab’,
inlined from ‘assemble_emit’ at Python/compile.c:5247:25,
inlined from ‘assemble’ at Python/compile.c:5525:18:
Python/compile.c:5201:19: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
5201 | *lnotab++ = k;
| ~~~~~~~~~~^~~
Python/compile.c: In function ‘compiler_visit_stmt’:
Python/compile.c:2970:1: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
2970 | compiler_visit_stmt(struct compiler *c, stmt_ty s)
| ^~~~~~~~~~~~~~~~~~~
Modules/main.c: In function ‘_PyCoreConfig_Copy’:
Modules/main.c:2495:47: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
2495 | #define COPY_ATTR(ATTR) config->ATTR = config2->ATTR
| ~~~~~~~^~~~~~
2496 | #define COPY_STR_ATTR(ATTR) \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2497 | do { \
| ~~~~~~
2498 | if (config2->ATTR != NULL) { \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2499 | config->ATTR = _PyMem_RawWcsdup(config2->ATTR); \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2500 | if (config->ATTR == NULL) { \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2501 | return -1; \
| ~~~~~~~~~~~~
2502 | } \
| ~~~
2503 | } \
| ~~~
2504 | } while (0)
| ~~~~~~~~~~~
2505 | #define COPY_WSTRLIST(LEN, LIST) \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2506 | do { \
| ~~~~~~
2507 | if (config2->LIST != NULL) { \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2508 | config->LIST = copy_wstrlist(config2->LEN, config2->LIST); \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2509 | if (config->LIST == NULL) { \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2510 | return -1; \
| ~~~~~~~~~~~~
2511 | } \
| ~~~
2512 | } \
| ~~~
2513 | config->LEN = config2->LEN; \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2514 | } while (0)
| ~~~~~~~~~~~
2515 |
|
2516 | COPY_ATTR(install_signal_handlers);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Modules/main.c: In function ‘_PyCoreConfig_Copy’:
Modules/main.c:2516:5: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
2516 | COPY_ATTR(install_signal_handlers);
| ^
Modules/main.c: In function ‘_PyCoreConfig_Copy’:
Modules/main.c:2516:5: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
2516 | COPY_ATTR(install_signal_handlers);
| ^
In function ‘assemble_lnotab’,
inlined from ‘assemble_emit’ at Python/compile.c:5247:0,
inlined from ‘assemble’ at Python/compile.c:5525:0:
Python/compile.c:5201: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
5201 | *lnotab++ = k;
|
In function ‘assemble_lnotab’,
inlined from ‘assemble_emit’ at Python/compile.c:5247:0,
inlined from ‘assemble’ at Python/compile.c:5525:0:
Python/compile.c:5201: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
5201 | *lnotab++ = k;
|
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/socketmodule.c: In function ‘getsockaddrarg’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/socketmodule.c:2194:9: warning: ‘strncpy’ specified bound 64 equals destination size [-Wstringop-truncation]
2194 | strncpy((char *)sa->salg_name, name, sizeof(sa->salg_name));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/socketmodule.c: In function ‘sock_sendmsg’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/socketmodule.c:4230:1: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
4230 | sock_sendmsg(PySocketSockObject *s, PyObject *args)
| ^~~~~~~~~~~~
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/socketmodule.c: In function ‘sock_sendmsg’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/socketmodule.c:4230:1: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
4230 | sock_sendmsg(PySocketSockObject *s, PyObject *args)
| ^
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/sha256module.c: In function ‘SHA256Type_copy’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/sha256module.c:78:22: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
78 | dest->local = src->local;
| ~~~^~~~~~~
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/sha256module.c: In function ‘SHA256Type_copy’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/sha256module.c:78:22: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
78 | dest->local = src->local;
| ^
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/sha512module.c: In function ‘SHA512Type_copy’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/sha512module.c:87:22: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
87 | dest->local = src->local;
| ~~~^~~~~~~
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/sha512module.c: In function ‘SHA512Type_copy’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/sha512module.c:87:22: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
87 | dest->local = src->local;
| ^
In file included from /home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/pyexpat.c:71:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/clinic/pyexpat.c.h: In function ‘pyexpat_ParserCreate’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/clinic/pyexpat.c.h:243:1: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
243 | pyexpat_ParserCreate(PyObject *module, PyObject *const *args, Py_ssize_t nargs, PyObject *kwnames)
| ^~~~~~~~~~~~~~~~~~~~
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/expat/xmlparse.c: In function ‘build_node’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/expat/xmlparse.c:6803:39: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
6803 | dest->type = dtd->scaffold[src_node].type;
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~
In file included from /home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/expat/expat_config.h:8,
from /home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/expat/xmltok.c:49:
./pyconfig.h:1526: warning: "_POSIX_C_SOURCE" redefined
1526 | #define _POSIX_C_SOURCE 200809L
|
In file included from /usr/include/bits/libc-header-start.h:33,
from /usr/include/string.h:26,
from /home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/expat/xmltok.c:34:
/usr/include/features.h:310: note: this is the location of the previous definition
310 | # define _POSIX_C_SOURCE 199506L
|
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/expat/xmlparse.c: In function ‘build_node’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/expat/xmlparse.c:6803:39: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
6803 | dest->type = dtd->scaffold[src_node].type;
| ^
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/_ctypes/_ctypes.c: In function ‘PyCSimpleType_new’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/_ctypes/_ctypes.c:2013:21: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
2013 | stgdict->length = 0;
| ~~~~~~~~~~~~~~~~^~~
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/_ctypes/_ctypes.c: In function ‘PyCSimpleType_new’:
/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Modules/_ctypes/_ctypes.c:2013:21: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5
2013 | stgdict->length = 0;
| ^
Task was destroyed but it is pending!
task: <Task pending coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending coro=<<async_generator_athrow without __name__>()>>
stty: 'standard input': Inappropriate ioctl for device
Exception in thread Thread-1563:
Traceback (most recent call last):
File "/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Lib/test/test_ssl.py", line 2392, in run
msg = self.read()
File "/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Lib/test/test_ssl.py", line 2369, in read
return self.sslconn.read()
File "/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Lib/ssl.py", line 931, in read
return self._sslobj.read(len)
ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:2570)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Lib/threading.py", line 926, in _bootstrap_inner
self.run()
File "/home/buildbot/buildarea/3.7.cstratak-fedora-stable-ppc64le.lto-pgo/build/Lib/test/test_ssl.py", line 2478, in run
raise ssl.SSLError('tlsv13 alert certificate required')
ssl.SSLError: ('tlsv13 alert certificate required',)
|
Sorry, something went wrong.
larryhastings
pushed a commit
that referenced
this pull request
Aug 4, 2020
…terface (GH-21033) (#21233) CVE-2020-14422: The __hash__() methods of classes IPv4Interface and IPv6Interface had issue of generating constant hash values of 32 and 128 respectively causing hash collisions. The fix uses the hash() function to generate hash values for the objects instead of XOR operation. (cherry picked from commit b30ee26) Co-authored-by: Ravi Teja P <rvteja92@gmail.com> Signed-off-by: Tapas Kundu <tkundu@vmware.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reviewers
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The hash() methods of classes IPv4Interface and IPv6Interface had issue
of generating constant hash values of 32 and 128 respectively causing hash collisions.
The fix uses the hash() function to generate hash values for the objects
instead of XOR operation
https://bugs.python.org/issue41004