OpenH264 Induces Headaches for Fedora

Did you know...?

LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

By Joe Brockmeier
June 2, 2025

Software patents and workarounds for them are, once again, causing headaches for open-source projects and users. This time around, Fedora users have been vulnerable to a serious flaw in the OpenH264 library for months—not for want of a fix, but because of the Rube Goldberg machine methodology of distributing the library to Fedora users. The software is open source under a two-clause BSD license; the RPMs are built and signed by Fedora, but the final product is distributed by Cisco, so the company can pick up the tab for license fees. Unfortunately, a breakdown in the process of handing RPMs to Cisco for distribution has left Fedora users vulnerable, and inaction on Fedora's part has left users unaware that they are at risk.

OpenH264 background

The Advanced Video Coding (AVC) video codec, often referred to as H.264, is a video-compression standard meant to provide reasonable video quality at lower bitrates than previous standards. It is widely used for video encoding and playback, not only for watching cat videos online but also for video conferencing. Various patents that apply to the standard were held by MPEG LA, which was later acquired by the Via Licensing Alliance. One public presentation from 2013 indicates that the going rate to acquire a license to appease the patent holders was $0.20 per unit (after 100,000 units) or $25 million a year, whichever was cheaper.

In 2013, Cisco announced the OpenH264 project, which not only provides source and binaries that implement the H.264 standard, Cisco also pays the licensing royalties through an arrangement it made with MPEG LA. However, there's a catch: a project or user has to use the binaries that are distributed by Cisco to take advantage of its deal with the license holders.

Projects cannot simply take the source and ship it with their software—at least, they cannot if they want to be certain that the patent holders won't come looking for a payout. If, say, Fedora actually hosts the repository with OpenH264 packages for its users, then it—or its users—will be responsible for the licensing fees. Since Fedora is not an independent entity, Red Hat would be responsible for the fees as the sponsor of Fedora. As it happens, Red Hat has (quite reasonably) been unwilling to roll the dice and ship OpenH264 in the hopes that it would escape the gaze of the license holders. It has been equally reluctant (also reasonably) to open its wallet for a fee that may well run in the millions of dollars each year.

In 2014, LWN covered some of the early problems that Fedora had with inclusion of OpenH264, and noted that Christian Schaller was working with Cisco on a way to build OpenH264 on Fedora's infrastructure for its users. Ultimately, as described on Fedora's OpenH264 page, Fedora was able to include the fedora-cisco-openh264 repository metadata, starting with Fedora 24, that would point users to Cisco-hosted packages built by Fedora. That included packages to use H.264 with GStreamer and Fedora's Firefox package. The repository was enabled by default with the Fedora 33 release.

Given the age of the standard, one might hope that the patents that apply to it would have expired or be close to expiring—but it's not that simple. As Michael Catanzaro explained in a 2023 discussion about OpenH264, it is unlikely that a current implementation of the standard will definitely be clear of patent encumbrances:

Unfortunately H.264 is extremely complicated because there are so many revisions to the specification, so even once the patents covering the original specification have expired, figuring out whether a particular decoder is legal or not still requires substantial technical expertise in addition to legal expertise. And that can change if the decoder implements any newer features in the future, which makes for an extremely challenging problem. That is to say, do not expect other H.264 decoders to be allowed in Fedora even when all patents covering the original spec have expired.

Thus, despite the fact that it is more than 22 years old, H.264 remains a patent headache, and Fedora is still having to perform a delicate dance with Cisco to avoid having liability for patent fees. Unfortunately, it takes two to tango—or, in this case, release OpenH264 packages.

Delays

CVE-2025-27091 was issued on February 20. It describes a vulnerability in the decoding function of OpenH264 that could allow a remote attacker to trigger a heap overflow in the library. If an attacker can entice a user into playing a video that exploits the vulnerability, it would be theoretically possible for the attacker to perform arbitrary commands on the victim's system. The CVE was given a severity rating of 8.6 out of ten. The upstream project released OpenH264 2.6.0, with a quiet fix for the vulnerability, on February 12.

Patrik Polakovič opened a ticket to update OpenH264 the same day that 2.6.0 was released. Unfortunately, there was a mismatch in the shared-library version. The Makefile for OpenH264 specified SHAREDLIB_MAJORVERSION=8, but the meson.build for the project was set to major_version = '7'. That stalled things on the Fedora side while trying to sort out the right library version—and before it was understood that there was a security vulnerability at play. Catanzaro bumped the ticket with a comment about the security advisory on February 24.

Following that, several tickets were opened to track progress on properly building the packages with the security fix; those were ultimately consolidated in a single ticket on February 27. The first set of packages was built the same day, but Catanzaro asked to hold off on sending them to Cisco for distribution while a 2.5.1 version release with the fix was created to avoid bumping the ABI version from 7 to 8. But it was not possible for Fedora to create its own version due to the patent issues.

Wim Taymans updated the ticket on March 12 to say that there were completed builds for Fedora 40, 41, and 42, as well as EPEL 10. The builds are visible in Koji, Fedora's build system, but they are not available for download. If users try to access the builds using Koji's download links, they will be directed to the Non-distributable-rpms page that explains that Fedora cannot distribute the RPMs for "various legal reasons".

After some discussion, Polakovič reported that he had tried to send the packages to Cisco as email attachments but received an error that "Red Hat Mail does not allow you to use this type of file as it violates Google policy for executables and archives". He asked later if Catanzaro knew how to get the RPMs to Cisco:

These licensing issues are the source of so much frustration. Ordinarily we'd just get the build and that's it. It's insane how many hoops we have to go through.

More discussion and complaints about the legal silliness followed. No one seemed to know how to achieve the task of alerting Cisco to the builds and ensuring that only Cisco employees could download the builds. In early April, Neal Gompa offered the contact information he used when communicating with Cisco from the openSUSE project, which followed Fedora's lead in distributing OpenH264. On April 21, Polakovič said that he had still not received a reply from Cisco and was not sure how to proceed.

Remove OpenH264?

More time passed and on May 8, Catanzaro said that it might be time to remove OpenH264 from Fedora "due to the high risk level and inability to release updates". Kevin Fenzi replied that he finally had contact with Cisco, "so I am hoping that this will be unblocked soon". Another update from Polakovič on May 13—three months after OpenH264 2.6.0 was released with a fix for the vulnerability—indicated that Cisco had provided Fedora with a link for uploading and that the packages were successfully submitted.

On May 28, Fenzi updated the ticket status to affirm that Fedora was still waiting on Cisco to update its repository.

The problem has also been raised and discussed on the fedora-devel mailing list. Chris Adams first asked at the end of April how to remove or replace the openh264 package, due to the vulnerability, without removing other packages. In late May, Jonathan Schleifer thanked Adams for raising the topic: "I had no idea Fedora would let something so serious be unfixed for so long". Stephen Smoogen responded that this was a predictable problem:

There is no incentive for the "partners" to fix these sorts of problems and there will always be a lot of incentive to put it off another day for whatever internal fires are going on. At this point, I think we should acknowledge that we as a project made a mistake and figure out how to fix this for our users.

Catanzaro said that Fedora was between a rock and a hard place. Without OpenH264 Fedora would have to "point to RPM Fusion and hope [users] can figure out how to get what they need from there". He later said that Fedora would need to remove OpenH264 if it cannot fix security issues in a timely manner. "If we knew that it would take this long to update, we would probably have done that already."

Current status

To date, it is unclear when updated packages will be available to Fedora users. The Fedora project has no viable options here. If it does not ship an H.264 implementation, its users are left to fend for themselves, which leads to complaints about complexity and a lack of parity with other Linux distributions or operating systems. It does not have the luxury of thumbing its nose at the patent cartel, nor a benefactor that wants to appease the cartel with bags of cash so that Fedora could supply OpenH264 to users directly. The Cisco arrangement, on paper, would seem to be the best option.

In practice, though, it has left Fedora unable to push an update to protect its users. But what is within Fedora's control is how it communicates with its users. It is mystifying that Fedora has not issued an advisory to warn its users that they are exposed to a security vulnerability. There may not be an easy fix for Fedora to provide, but it could advise of workarounds or at least ensure that users are aware that they are vulnerable and allow them to seek their own remedies.

This situation demonstrates, once again, the fragility of depending on a corporate benefactor providing a service. Just because a team at a company is well-staffed and offering to lend a hand today does not guarantee that will be the case tomorrow or the day after. Management can have a change of heart, priorities will shift, people may get busy or leave for other jobs, institutional knowledge can be lost, and then things fall through the cracks.

This story has been replayed in open-source projects enough times to be familiar to all but the newest folks in the community. We've all seen this movie before, and it does not improve with repeated viewings or remakes.

---