Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

bpo-41004: Resolve hash collisions for IPv4Interface and IPv6Interface #21033

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jun 29, 2020

Conversation

rvteja92
Copy link
Contributor

@rvteja92 rvteja92 commented Jun 21, 2020

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

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
@the-knights-who-say-ni
Copy link

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 Missing

Our records indicate the following people have not signed the CLA:

@rvteja92

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
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

Lib/test/test_ipaddress.py Outdated Show resolved Hide resolved
Lib/test/test_ipaddress.py Outdated Show resolved Hide resolved
@bedevere-bot
Copy link

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!

Lib/test/test_ipaddress.py Outdated Show resolved Hide resolved
Lib/test/test_ipaddress.py Outdated Show resolved Hide resolved
@ericvsmith ericvsmith merged commit b30ee26 into python:master Jun 29, 2020
@miss-islington
Copy link
Contributor

Thanks @rvteja92 for the PR, and @ericvsmith for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8, 3.9.
🐍🍒⛏🤖

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>
@bedevere-bot
Copy link

GH-21220 is a backport of this pull request to the 3.9 branch.

@bedevere-bot bedevere-bot removed the needs backport to 3.9 only security fixes label Jun 29, 2020
@bedevere-bot
Copy link

GH-21221 is a backport of this pull request to the 3.8 branch.

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>
@rvteja92 rvteja92 deleted the bpo-41004 branch June 29, 2020 18:00
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>
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot PPC64LE Fedora Stable LTO + PGO 3.7 has failed when building commit b98e779.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/429/builds/130) and take a look at the build logs.
  4. Check if the failure is related to this commit (b98e779) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

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 logs
remote: 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',)

arun-mani-j pushed a commit to arun-mani-j/cpython that referenced this pull request Jul 21, 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
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.