NotificationsYou must be signed in to change notification settings
Fork32.1k
Star67.3k

[3.13] gh-119511: Fix a potential denial of service in imaplib (GH-119514)#129355

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Merged

gpshead merged 1 commit intopython:3.13frommiss-islington:backport-735f25c-3.13

Jan 27, 2025

Merged

[3.13] gh-119511: Fix a potential denial of service in imaplib (GH-119514)#129355

gpshead merged 1 commit intopython:3.13frommiss-islington:backport-735f25c-3.13

Jan 27, 2025

Conversation

Copy link

Contributor

miss-islington commentedJan 27, 2025•
edited by bedevere-appbot
Loading

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit735f25c)

Co-authored-by: Serhiy Storchakastorchaka@gmail.com
Co-authored-by: Gregory P. Smithgreg@krypto.org

Issue:OOM vulnerability in the imaplib module #119511

pythongh-119511: Fix a potential denial of service in imaplib (python…

5801b50

…GH-119514)The IMAP4 client could consume an arbitrary amount of memory when tryingto connect to a malicious server, because it read a "literal" data with asingle read(size) call, and BufferedReader.read() allocates the bytesobject of the specified size before reading. Now the IMAP4 client reads databy chunks, therefore the amount of used memory is limited by theamount of the data actually been sent by the server.(cherry picked from commit735f25c)Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>Co-authored-by: Gregory P. Smith <greg@krypto.org>