Since a few weeks ago, librsvg is now in oss-fuzz — Google's constantly-running fuzz-testing for OSS projects — and the crashes have started coming in. I'll have a lot more to say soon about crashes in Cairo, which is where the majority of the bugs are so far, but for now I want to tell you about a little bug I just fixed.

The fuzzer found a memory leak that happens when librsvg tries to parse an invalid XML document that has definitions for XML entities — the things that you normally reference like &foo; in the middle of the XML.

For example, this invalid document causes librsvg to leak:

<!DOCTYPEY[<!ENTITY a ''

Valgrind reports this:

$ valgrind --leak-check=full ./target/debug/rsvg-convert leak.svg 
...
Error reading SVG leak.svg: XML parse error: Error domain 1 code 37 on line 2 column 1 of data: xmlParseEntityDecl: entity a not terminated

==3750== 
==3750== HEAP SUMMARY:
==3750==     in use at exit: 78,018 bytes in 808 blocks
==3750==   total heap usage: 1,405 allocs, 597 frees, 205,161 bytes allocated
==3750== 
==3750== 247 (144 direct, 103 indirect) bytes in 1 blocks are definitely lost in loss record 726 of 750
==3750==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3750==    by 0x4BD857F: xmlCreateEntity (entities.c:158)
==3750==    by 0x4BD932B: xmlNewEntity (entities.c:451)
==3750==    by 0x2EBC75: rsvg::xml::xml2_load::sax_entity_decl_cb (xml2_load.rs:152)
==3750==    by 0x4BED6D8: xmlParseEntityDecl (parser.c:5647)
==3750==    by 0x4BEF4F3: xmlParseMarkupDecl (parser.c:7024)
==3750==    by 0x4BEFB95: xmlParseInternalSubset (parser.c:8558)
==3750==    by 0x4BF50E9: xmlParseDocument (parser.c:11072)
==3750==    by 0x2ED266: rsvg::xml::xml2_load::Xml2Parser::parse (xml2_load.rs:466)
==3750==    by 0x4A8C49: rsvg::xml::XmlState::parse_from_stream::{{closure}} (mod.rs:628)
==3750==    by 0x2ACA92: core::result::Result<T,E>::and_then (result.rs:1316)
==3750==    by 0x34D4E2: rsvg::xml::XmlState::parse_from_stream (mod.rs:627)
==3750== 
==3750== LEAK SUMMARY:
==3750==    definitely lost: 144 bytes in 1 blocks
==3750==    indirectly lost: 103 bytes in 3 blocks
==3750==      possibly lost: 0 bytes in 0 blocks
==3750==    still reachable: 73,947 bytes in 746 blocks
==3750==         suppressed: 0 bytes in 0 blocks

Let's see what happened.

The code in question

Even after the port to Rust, librsvg still uses libxml2 for parsing XML. So, librsvg has to deal with raw pointers incoming from libxml2 and it must do their memory management itself, since the Rust compiler doesn't know what to do with them automatically.

Librsvg uses the SAX parser, which involves setting up callbacks to process events like "XML element started", or "an entity was defined".

If you have a valid document that has entity definitions like these:

<!ENTITY foo "#aabbcc">
<!ENTITY bar "some text here">

Then libxml2's SAX parser will emit two events to instruct your code that it should define entities, one for foo and one for bar, with their corresponding content. Librsvg stores these in a hash table, since it has to be able to retrieve them later when the SAX parser requests it. In detail, libxml2 requires that you create an xmlEntityPtr by calling xmlNewEntity() and then keep it around.

xmlEntityPtr xmlNewEntity (xmlDocPtr      doc,
                           const xmlChar *name,
                           int            type,
                           const xmlChar *ExternalID,
                           const xmlChar *SystemID,
                           const xmlChar *content);

Later, you must free each of your stored entities with xmlFreeNode() (it supports different data types, including entities), or if you are using libxml2 2.12.0 or later, with xmlFreeEntity().

void xmlFreeNode (xmlNodePtr node);
void xmlFreeEntity (xmlEntityPtr entity);

Librsvg creates a SAX parser from libxml2, calls it to do the parsing, and then frees the entities at the end. In the following code, XmlState is the struct that librsvg uses to hold the temporary state during parsing: a partially-built XML tree, some counters on the number of loaded elements, the current element being processed, things like that. The build_document() method is called at the very end of XmlState's lifetime; it consumes the XmlState and returns either a fully-parsed and valid Document, or an error.

struct XmlState {
    inner: RefCell<XmlStateInner>,  // the mutable part

    // ... other immutable fields here
}

type XmlEntityPtr = *mut libc::c_void;

struct XmlStateInner {
    // ... a few fields for the partially-built XML tree, current element, etc.
    document_builder: DocumentBuilder,

    // Note that neither XmlStateInner nor Xmlstate implement Drop.
    //
    // An XmlState is finally consumed in XmlState::build_document(), and that
    // function is responsible for freeing all the XmlEntityPtr from this field.
    //
    // (The structs cannot impl Drop because build_document()
    // destructures and consumes them at the same time.)
    entities: HashMap<String, XmlEntityPtr>,
}

impl XmlState {
    fn build_document(
        self,
        stream: &gio::InputStream,
        cancellable: Option<&gio::Cancellable>,
    ) -> Result<Document, LoadingError> {
        // does the actual parsing with a libxml2 SAX parser
        self.parse_from_stream(stream, cancellable)?;

        // consume self, then consume inner, then consume document_builder by calling .build()
        let XmlState { inner, .. } = self;
        let mut inner = inner.into_inner();

        // Free the hash of XmlEntityPtr.  We cannot do this in Drop because we will
        // consume inner by destructuring it after the for() loop.
        for (_key, entity) in inner.entities.drain() {
            unsafe {
                xmlFreeNode(entity);
            }
        }

        let XmlStateInner {
            document_builder, ..
        } = inner;
        document_builder.build()
    }
}

There are many Rust-isms in this code.

• After doing the actual parsing with parse_from_stream(), self is destructured to consume it and extract its inner field, which is the actual mutable part of the XML loading state.

• The code frees each xmlEntityPtr stored in the hash table of entities.

• The inner value, which is an XmlStateInner, is destructured to extract the document_builder field, which gets asked to .build() the final document tree.

Where's the bug?

The bug is in this line at the beginning of the build_document() function:

        self.parse_from_stream(stream, cancellable)?;

The ? after the function call is to return errors to the caller. However, if there is an error during parsing, we will exit the function here, and it will not have a chance to free the values in the key-value pairs among the entities ! Memory leak!

This code had already gone through a few refactorings. Initially I had an impl Drop for XmlState which did the obvious thing of freeing the entities by hand:

impl Drop for XmlState {
    fn drop(&mut self) {
        unsafe {
            let mut inner = self.inner.borrow_mut();

            for (_key, entity) in inner.entities.drain() {
                // entities are freed with xmlFreeNode(), believe it or not
                xmlFreeNode(entity);
            }
        }
    }
}

But at one point, I decided to clean up the way the entire inner struct was to be handled, and decided to destructure it at the end of its lifetime, since that made the code simpler. However, destructuring an object means that you cannot have an impl Drop for it, since then some fields are individually moved out and some are not during the destructuring. So, I changed the code to free the entities directly into build_document() as above.

I missed the case where the parser can exit early due to an error.

The Rusty solution

Look again at how the entities hash table is declared in the struct fields:

type XmlEntityPtr = *mut libc::c_void;

struct XmlStateInner {
    entities: HashMap<String, XmlEntityPtr>,
}

That is, we are storing a hash table with raw pointers in the value part of the key-value pairs. Rust doesn't know how to handle those external resources, so let's teach it how to do that.

The magic of having an impl Drop for a wrapper around an unmanaged resource, like xmlEntityPtr, is that Rust will automatically call that destructor at the appropriate time — in this case, when the hash table is freed.

So, let's use a wrapper around XmlEntityPtr, and add an impl Drop for the wrapper:

struct XmlEntity(xmlEntityPtr);

impl Drop for XmlEntity {
    fn drop(&mut self) {
        unsafe {
            xmlFreeNode(self.0);
        }
    }
}

And then, let's change the hash table to use that wrapper for the values:

    entities: HashMap<String, XmlEntity>,

Now, when Rust has to free the HashMap, it will know how to free the values. We can keep using the destructuring code in build_document() and it will work correctly even with early exits due to errors.

Valgrind's evidence without the leak

# valgrind --leak-check=full ./target/debug/rsvg-convert leak.svg 
==5855== Memcheck, a memory error detector
==5855== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==5855== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==5855== Command: ./target/debug/rsvg-convert leak.svg
==5855== 
Error reading SVG leak.svg: XML parse error: Error domain 1 code 37 on line 2 column 1 of data: xmlParseEntityDecl: entity a not terminated

==5855== 
==5855== HEAP SUMMARY:
==5855==     in use at exit: 77,771 bytes in 804 blocks
==5855==   total heap usage: 1,405 allocs, 601 frees, 205,161 bytes allocated
==5855== 
==5855== LEAK SUMMARY:
==5855==    definitely lost: 0 bytes in 0 blocks
==5855==    indirectly lost: 0 bytes in 0 blocks
==5855==      possibly lost: 0 bytes in 0 blocks
==5855==    still reachable: 73,947 bytes in 746 blocks
==5855==         suppressed: 0 bytes in 0 blocks

Moral of the story

Resources that are external to Rust really work best if they are wrapped at the lowest level, so that destructors can run automatically. Instead of freeing things by hand when you think it's right, let the compiler do it automatically when it knows it's right. In this case, wrapping xmlEntityPtr with a newtype and adding an impl Drop is all that is needed for the rest of the code to look like it's handling a normal, automatically-managed Rust object.

Dear Tumbleweed users and hackers,

It’s the week before openSUSE Conference, when all through the world, contributors get ready to travel. People might be busy with their final preparations to meet at the conference next week, and prepare their slides for the talks, but nothing can stop them from keeping Tumbleweed rolling. This week, we have received 5 snapshots (0613, 0614, 0617, 0618, and 0619)

The most relevant updates included were:

• libxml 2.12.8
• Ruby 3.3.3
• VLC 3.0.21, see http://www.videolan.org/security/sb-vlc3021.html
• Mesa 24.0.9, 24.1.0 & 24.1.1: Mesa 24 brought some graphical glitches on AMD/.ATI graphic cards, which we could not catch in openQA. A (mostly) fixed version was published in the update channel to shorten the time)
• Mozilla Firefox 127.0
• KDE Gear 24.05.1
• Linux kernel 6.9.4 & 6.9.5

Staging projects are currently testing the integration of these changes:

• KDE Plasma 6.1
• NodeJS 22.3.0
• Perl 5.40.0
• transactional-update: enable soft reboot; see https://microos.opensuse.org/blog/2024-06-13-soft-reboot/
• Pytest 8.2
• dbus-broker: some networking issue after upgrades left to work out
• GCC 14: phase 2: use gcc14 as the default compiler – lots of help needed: https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc7

With all this, I am looking forward to seeing many of you at the openSUSE conference in Nuremberg next week!

Leap 15.6 install media were refreshed to address an issue with old secure boot signing key for ppc64le and s390x.

Refreshed images from Leap 15.6 Build 710.3 are already available for download at get.opensuse.org. So now you can enjoy installation with secure boot on more exotic architectures.

Happy Hacking!

_{^{(Image made with DALL-E)}}

Here is a little gift for the weekend. openSUSE Leap Micro 6.0 RC is now available! Images can be found at get.opensuse.org.

The main difference from Beta is a working upgrade path from 5.5 and slightly smoother upgrade support to commercial products. So let’s test it out.

Upgrade instructions

I’d personally recommend a clean install, especially in between major versions on a system that can be redeployed with self-install within 2 minutes. At the same time, the online upgrade takes longer. Another aspect to consider is that we don’t have a developed migration test suite for online migration, unlike for Leap 15.X.

The easiest way to test the upgrade would be in a VM. Get Leap micro 5.5 images from get.opensuse.org and ensure you have all updates applied via transactional-update.

I’d recommend upgrading to 6.0 via SSH or console instead of cockpit, as the service might stop responding. Upgrade instructions and known issues are captured in the SDB:System_upgrade_to_LeapMicro_6.0 wiki page.

Make sure to check known issues before proceeding.

Documentation

Please refer to SLE Micro 6.0 documentation including Release notes.

Reporting Issues

Please refer to the Leap Micro section in our Submitting bug reports page.

Next steps

Leap Micro 6.0 GA can be expected before oSC2024 next week.

openSUSE Leap Micro 6.0 Beta is now available! We expect that it will very quickly transition to RC and GA as the infra readiness advances. Leap Micro 6.0 Beta images can be found at get.opensuse.org or directly at download.opensuse.org.

About Leap Micro

Leap Micro 6.0 is a rebranded SUSE Linux Enterprise Micro 6.0 which is an ultrareliable container and VM host by SUSE. This is the first publicly released product based on the fresh code base “SUSE Linux Framework One” (previously known as ALP).

Leap Micro 6.X is available for x86_64 and aarch64, released every 6 months, and supported until the next-next release is out. That means that Leap Micro 6.0 will become EOL once Leap Micro 6.2 gets released.

All pieces related to Rancher and Elemental are purposely excluded from Leap Micro 6.X as SLE Micro for Rancher is free for use without any subscription within Rancher deployments.

No more traditional installer

Leap Micro 6.X is deployed via self-install image which writes a preconfigured image to the disk and enlarges root partition. Users can use combustion, ignition or default to the jeos-firstboot wizard to do the initial setup of the system.

Do not get mistaken by the availability of openSUSE-Leap-Micro-6.0-*.iso is not installable. We refer to the image as a Packages image, which is basically an offline repository on a DVD.

New FDE, VMWare, and Cloud images

Aside from the self-install image Micro 6.0 comes with qcow, Full Disk Encryption, and RealTime images. All images can be found at download.opensuse.org

For the first time Leap Micro 6.X has also cloud-init therefore shortly after the release we will also have cloud images available on GCP, Azure, and AWS.

Changes to the product building

Leap Micro 6.X is using the new product composer instead of the old product builder. This allowed us to consume update-info from the newly designed maintenance workflow of SLE Micro 6.0 and was preferred by the openSUSE maintenance team.

Changes to the repositories and maintenance workflow

Leap Micro 5.X users receive all updates released for relevant SLE Micro version via a repository named repo-sle-update. This particular repository no longer exists in Leap Micro 6.X.

Instead, the repo-main repository will contain all released updates for the relevant version of SUSE Linux Micro to date.

Please note that the repository path slightly changed too, we’ll ensure that migration via transactional-update shell followed by zypper dup –releaser 6.0 works via compatibility symlinks on download server.

New way of managing repository definitions

openSUSE-repos is not new to our users, however, for the first time, openSUSE Leap Micro 6.0 deployments come with openSUSE-repos preinstalled. openSUSE repos uses a local RIS service that easily lets us maintain repository definitions with a package update.

Users migrating from 5.5/5.4 releases are advised to install zypper in openSUSE-repos to ensure they have up-to-date repository paths.

Documentation

Please refer to SLE Micro 6.0 documentation including Release notes.

Reporting Issues

Please refer to the Leap Micro section in our Submitting bug reports page.

Next steps

Missing maintenance setup was a long-term blocker for the transition out from Alpha, otherwise, the distribution itself is stable and feature-full. Now that we have it, we need to polish some remaining infrastructure issues and users can expect a release within the next few days. Ideally before oSC2024 next week.

Dear Tumbleweed users and hackers,

The week was unspectacular, seeing that staging projects mostly were in and out within 24 hours. We, the release managers, like this, as it implies that the package maintainers submitted things that worked and did not need much of our extra attention. This does not mean that nothing was going through; the opposite is the case: just over 500 requests have been accepted in the last 7 days.

Out of this, we produced, tested, and published 5 snapshots (0607, 0609, 0610, 0611, and 0612), containing these changes:

• LibreOffice 24.2.4
• KDE Frameworks 6.3.0
• PHP 8.3.8
• libeconf 0.7.1
• Cups 2.4.8
• Cmake 3.29.4
• python setuptools 70.0

Currently, we have these things in stagings, which will mostly be delivered in the next few days (except the long-lasting ones, which you all know from the previous few weeks:

• libxml 2.12.8
• Mesa 24.0.9
• Mozilla Firefox 127.0
• KDE Gear 24.05.1
• Linux kernel 6.9.4 & LTS 6.6.33
• NodeJS 22.3.0
• Pytest 8.2
• dbus-broker: some networking issue after upgrades left to work out
• GCC 14: phase 2: use gcc14 as the default compiler – lots of help needed: https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc7

I've been posting a few sketches on my mastodon every Friday. They are mostly sketches of application icon design process, but not always. Follow, like, subscribe!

I’ve been posting a few sketches on my mastodon every Friday. They are mostly sketches of application icon design process, but not always. Follow, like, subscribe!