Those CVEs were announced here: https://www.openwall.com/lists/oss-security/2023/11/16/1 Mageia 8 and 9 are also affected.
CC: (none) => nicolas.salgueroWhiteboard: (none) => MGA9TOO, MGA8TOOSource RPM: (none) => vim-9.0.2087-1.mga9.src.rpm
Status comment: (none) => Fixed upstream in 9.0.2112
Excuse me doing this, Nicolas, but you not only committed the current vim version, also many previous ones because of security issues.
CC: nicolas.salguero => (none)Assignee: bugsquad => nicolas.salguero
CVE-2023-48706 was announced here: https://www.openwall.com/lists/oss-security/2023/11/22/3
Status comment: Fixed upstream in 9.0.2112 => Fixed upstream in 9.0.2121Summary: vim new security issues CVE-2023-4823[1-7] => vim new security issues CVE-2023-4823[1-7] and CVE-2023-48706Assignee: nicolas.salguero => pkg-bugs
For Cauldron and Mageia 9, version 9.0.2130 is into SVN.
Suggested advisory: ======================== The updated packages fix security vulnerabilities: When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. (CVE-2023-48231) A floating point exception may occur when calculating the line offset for overlong lines and smooth scrolling is enabled and the cpo-settings include the 'n' flag. This may happen when a window border is present and when the wrapped line continues on the next physical line directly in the window border because the 'cpo' setting includes the 'n' flag. Only users with non-default settings are affected and the exception should only result in a crash. (CVE-2023-48232) If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large. Impact is low, user interaction is required and a crash may not even happen in all situations. (CVE-2023-48233) When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. (CVE-2023-48234) When parsing relative ex addresses one may unintentionally cause an overflow. Ironically this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow. Impact is low, user interaction is required and a crash may not even happen in all situations. (CVE-2023-48235) When using the z= command, the user may overflow the count with values larger than MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. (CVE-2023-48236) In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. (CVE-2023-48237) When executing a `:s` command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive `:s` call causes free-ing of memory which may later then be accessed by the initial `:s` command. The user must intentionally execute the payload and the whole process is a bit tricky to do since it seems to work only reliably for the very first :s command. It may also cause a crash of Vim. (CVE-2023-48706) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48231 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48232 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48233 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48234 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48235 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48236 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48237 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48706 https://www.openwall.com/lists/oss-security/2023/11/16/1 https://www.openwall.com/lists/oss-security/2023/11/22/3 ======================== Updated packages in core/updates_testing: ======================== vim-X11-9.0.2130-1.mga9 vim-common-9.0.2130-1.mga9 vim-enhanced-9.0.2130-1.mga9 vim-minimal-9.0.2130-1.mga9 from SRPM: vim-9.0.2130-1.mga9.src.rpm
Whiteboard: MGA9TOO, MGA8TOO => (none)Status comment: Fixed upstream in 9.0.2121 => (none)Assignee: pkg-bugs => qa-bugsVersion: Cauldron => 9
Status: NEW => ASSIGNED
Advisory from comment 4 added to SVN. Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"
CC: (none) => marja11Keywords: (none) => advisory
May we take this opportunity to include in this update the fix for haproxy config files paths ? I updated SOURCES/vim-9.0-add-haproxy-syntax.patch and triggered a rebuild with this change. Revert if it's not acceptable to include this fix. Change in runtime/filetype.vim: -+au BufNewFile,BufRead haproxy.conf,*/etc/haproxy/*.conf setf haproxy ++au BufNewFile,BufRead */etc/haproxy/*.cfg,*/etc/haproxy/haproxy.conf setf haproxy Revert and tell me if I need to create a separate bugfix update.
CC: (none) => mageia
Suggested advisory: ======================== The updated packages fix security vulnerabilities: When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. (CVE-2023-48231) A floating point exception may occur when calculating the line offset for overlong lines and smooth scrolling is enabled and the cpo-settings include the 'n' flag. This may happen when a window border is present and when the wrapped line continues on the next physical line directly in the window border because the 'cpo' setting includes the 'n' flag. Only users with non-default settings are affected and the exception should only result in a crash. (CVE-2023-48232) If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large. Impact is low, user interaction is required and a crash may not even happen in all situations. (CVE-2023-48233) When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. (CVE-2023-48234) When parsing relative ex addresses one may unintentionally cause an overflow. Ironically this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow. Impact is low, user interaction is required and a crash may not even happen in all situations. (CVE-2023-48235) When using the z= command, the user may overflow the count with values larger than MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. (CVE-2023-48236) In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. (CVE-2023-48237) When executing a `:s` command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive `:s` call causes free-ing of memory which may later then be accessed by the initial `:s` command. The user must intentionally execute the payload and the whole process is a bit tricky to do since it seems to work only reliably for the very first :s command. It may also cause a crash of Vim. (CVE-2023-48706) The update fixes as well haproxy configuration paths used for syntax coloration. References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48231 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48232 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48233 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48234 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48235 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48236 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48237 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48706 https://www.openwall.com/lists/oss-security/2023/11/16/1 https://www.openwall.com/lists/oss-security/2023/11/22/3 ======================== Updated packages in core/updates_testing: ======================== vim-X11-9.0.2130-2.mga9 vim-common-9.0.2130-2.mga9 vim-enhanced-9.0.2130-2.mga9 vim-minimal-9.0.2130-2.mga9 from SRPM: vim-9.0.2130-2.mga9.src.rpm
@Raphael Gertz: Please next time when you fix a MGA9 package use "%define subrel X" and not bumping the rel %mkrel 1 -> %mkrel 2 = NOT VALID But this YES VALID: %define subrel 1 Release: %mkrel 1 In a stable release this is the right mageia policy packaging. Thanks in advance!
CC: (none) => geiger.david68210
(In reply to David GEIGER from comment #8) > @Raphael Gertz: > > Please next time when you fix a MGA9 package use "%define subrel X" and not > bumping the rel > > %mkrel 1 -> %mkrel 2 = NOT VALID > > > But this YES VALID: > > %define subrel 1 > Release: %mkrel 1 > > > In a stable release this is the right mageia policy packaging. > > Thanks in advance! Really sorry for my mistake.
Tested in Real Hardware with Mageia 9 x86_64 lxqt Current vim packages in my system rpm -qa|grep vim vim-minimal-9.0.2087-1.mga9 vim-common-9.0.2087-1.mga9 Updated without issues Tested with some files I don't search for POC
(In reply to katnatek from comment #10) > Tested in Real Hardware with Mageia 9 x86_64 lxqt > > Current vim packages in my system > > rpm -qa|grep vim > vim-minimal-9.0.2087-1.mga9 > vim-common-9.0.2087-1.mga9 > > Updated without issues > Tested with some files > > I don't search for POC After the update rpm -qa|grep vim vim-common-9.0.2130-2.mga9 vim-minimal-9.0.2130-2.mga9
Whiteboard: (none) => MGA9-64-OK
Validating.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2023-0341.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED