2.4.2 breaks user iterations for LDAP
Hello everyone,
Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed.
It’s also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database.
This is however an issue for user iteration with LDAP, as documented here LDAP | Dovecot CE <https://doc.dovecot.org/2.4.2/core/config/auth/databases/ldap.html#user-iteration> . Such a userdb only has iterate_filter fields that would inherently not be containing any user variables.
The call to auth_cache_parse_key_and_fields() uses a combination of ldap_base and userdb_ldap_filter anyway (so whatever is in iterate_filter isn’t considered), and for an iteration userdb as described in the documentation, the latter would be empty.
Alas, I ended up getting the rather confusing error
- auth: Fatal: auth-cache: dc=rev-crew,dc=info: Cache key must contain at least one variable
With dc=rev-crew,dc=info being my ldap_base setting for the iteration userdb. I’m not critically dependent on the user iteration, so I’ve commented the userdb out for now, but this would need fixing.
Regards,
Christian Pfeiffer
Hello everyone,
Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed.
It's also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database.
This is however an issue for user iteration with LDAP, as documented here [1]LDAP | Dovecot CE. Such a userdb only has iterate_filter fields that would inherently not be containing any user variables.
The call to auth_cache_parse_key_and_fields() uses a combination of ldap_base and userdb_ldap_filter anyway (so whatever is in iterate_filter isn't considered), and for an iteration userdb as described in the documentation, the latter would be empty.
Alas, I ended up getting the rather confusing error
o auth: Fatal: auth-cache: dc=rev-crew,dc=info: Cache key must contain
at least one variableWith dc=rev-crew,dc=info being my ldap_base setting for the iteration userdb. I'm not critically dependent on the user iteration, so I've commented the userdb out for now, but this would need fixing.
Regards,
Christian Pfeiffer
References
Visible links
On 6. Nov 2025, at 2.52, cpfeiffer--- via dovecot <dovecot@dovecot.org> wrote:
Hello everyone,
Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed.
It's also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database.
This is however an issue for user iteration with LDAP, as documented here [1]LDAP | Dovecot CE. Such a userdb only has iterate_filter fields that would inherently not be containing any user variables.
Do you have a separate userdb now for ldap userdb lookups? That was the intention at least that usually the userdb filter and iteration would be in the same userdb, not separate ones. Anyway, I'll try to figure out a fix.
I guess that's not saying it very clearly.
Yes, I do. The relevant part of my config is:
ldap_uris = ldaps://ldap.rev-crew.info ldap_auth_dn = cn=dovecot,ou=Services,dc=rev-crew,dc=info ldap_auth_dn_password = ... ldap_base = dc=rev-crew,dc=info
passdb ldap { driver = ldap ldap_filter = (&(objectClass=mailRecipient)(mailRoutingAddress=%{user})) passdb_ldap_bind = yes fields { user=%{ldap:mailRoutingAddress} } }
userdb static { fields { uid=vmail gid=vmail home=/var/mail/vmail/%{user | domain}/%{user | username} } }
#userdb ldap {
driver = ldap
iterate_filter = (objectClass=mailRecipient)
passdb_ldap_bind = yes
iterate_fields {
user=%{ldap:mailRoutingAddress}
}
#}
The second, commented out userdb is just for iterating users, just like in the documentation. In my use case, I don't need need to dynamically look up attributes from the user, so I'm using a static userdb for that, but to be able to iterate users, that second userdb would be needed. I've commented it out for the moment to keep things running.
-----Original Message----- From: Timo Sirainen <timo@sirainen.com> Sent: 06 November 2025 10:52 To: cpfeiffer@rev-crew.info Cc: dovecot@dovecot.org Subject: Re: 2.4.2 breaks user iterations for LDAP
On 6. Nov 2025, at 2.52, cpfeiffer--- via dovecot <dovecot@dovecot.org> wrote:
Hello everyone,
Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed.
It's also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database.
This is however an issue for user iteration with LDAP, as documented here [1]LDAP | Dovecot CE. Such a userdb only has iterate_filter fields that would inherently not be containing any user variables.
Do you have a separate userdb now for ldap userdb lookups? That was the intention at least that usually the userdb filter and iteration would be in the same userdb, not separate ones. Anyway, I'll try to figure out a fix.
I guess that's not saying it very clearly.
participants (2)
-
cpfeiffer＠rev-crew.info
-
Timo Sirainen