On 1/18/26 9:32 AM, G.W. Haywood wrote:
Hi there,
On Sat, 17 Jan 2026, jbk wrote:
... thoughts / questions on the zlib CVE.
Can we be specific about which CVE?
There are two path's of vulnerability for the BackupPC server. One
is the distro installed zlib and the other is the zlib bundled in
BackupPC to date.
Assuming that you're restricting your consideration of vulnerabilities
to those in zlib and the zlib bundled by BackupPC, then yes. Although
the subject is "BackupPC-XS ...", to date not only BackupPC-XS but the
original rsync and rsync-bpc *also* bundle zlib. So, I gather, do a
number of other packages. As far as rsync-bpc is concerned I'm in the
midst of dealing with it - see below.
The distro installed zlib supposedly will be patched soon, not as of
yet. Anyone who has access to this server could avail themselves of
the vulnerability till it is patched.
Are all the big distros not all up to speed with zlib patches? That
may beg the questions (a) which distro? and (b) to whom do you permit
what kinds of access to your backup server?
Once it is patched then the only users who have access to the
bundled zlib are those trusted BackupPC admin users. The client
users shouldn't have direct access to the bundled zlib, correct?
I'm not sure that I follow.
To make use of flaws in the bundled zlib library, direct access to the
bundled library is not a requirement. If (and *only* if) (1) BackupPC
is linked with the vulnerable library and (2) there's some way for an
attacker to get a vulnerable function called, all the attacker must do
is somehow arrange for BackupPC to pipe through zlib data which our
attacker has somehow contrived to cause BackupPC to make a call to the
vulnerable function (and for this call to do something of use to the
attacker, but that's his problem).
In the case of BackupPC I'm not sure how easy it would be to arrange
for these conditions to be met, but it could theoretically be achieved
by getting BackupPC to back up or recover a crafted file. (If users
can e.g. run a compiler on the server they can alternatively download
vulnerable code (any vulnerable code, not just zlib) and build it.
Then they can do what they like with it. I've done that for example
to hack into a Debian box when the owner forgot the root password.
Just trying to get an idea of the risk level for the bundled zlib.
In my view, if you're running a vulnerable zlib it's low if you're
(otherwise) sane - but since compiling the bundled zlib in the first
place is optional, avoiding the risk seems trivial.
FWIW I think I'm very close to releasing rsync-bpc version 3.4.1.0rc1,
which is hopefully going to put this one to bed at last for BackupPC.
The new version will use both the system zlib and the system popt and
will bundle neither.
The CVE is https://www.cve.org/CVERecord?id=CVE-2026-22184 and marked
disputed. See also
https://www.openwall.com/lists/oss-security/2026/01/06/5
This was patched very quickly by some distributions even though the
problem is not in zlib. This is a bug in a *contibuted reference
program* demonstrating how to use zlib. This is not a problem in zlib
itself.
See the thread at https://github.com/madler/zlib/issues/1142
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
