Dear Maintainer,

debian/patches/0009_CVE-2026-81524.patch (the backport of upstream
CDRIVER-6424, "validate db and collection names") breaks
mongoc_collection_aggregate() for every collection.  It always returns a
cursor in the error state:

  database name "<db>.<collection>" invalid: contains "."

== Cause ==

The patch adds a "db" parameter to _mongoc_aggregate(), but declares it in a
different position than it defines it.

  mongoc-aggregate-private.h (declaration):
      _mongoc_aggregate (mongoc_client_t *client,
                         const char *ns,
                         const char *db,
                         mongoc_query_flags_t flags, ...

  mongoc-aggregate.c (definition):
      _mongoc_aggregate (mongoc_client_t *client,
                         const char *db,
                         const char *ns,
                         mongoc_query_flags_t flags, ...

The callers follow the declaration, for example in mongoc-collection.c:

      return _mongoc_aggregate (collection->client,
                                collection->ns,
                                collection->db,
                                flags, ...

Inside the function, "db" therefore holds collection->ns ("mydb.mycoll") and
"ns" holds collection->db.  The new check

      if (!_mongoc_cursor_check_db_name(cursor, db))

rejects the joined namespace because it contains ".".

Upstream 2.5.1 has the parameters in the same order in the declaration and
the definition (ns, db), so it is not affected.  mongoc_database_aggregate()
passes db->name for both arguments, so it works by accident.

== Reproducer ==

#include <mongoc/mongoc.h>   /* <mongoc.h> on 1.x */
#include <stdio.h>
int main(void) {
  bson_error_t e; mongoc_init();
  mongoc_client_t *c = mongoc_client_new("mongodb://127.0.0.1:27017/");
  mongoc_collection_t *col = mongoc_client_get_collection(c, "testdb",
"coll");
  bson_t *p = bson_new();                       /* empty pipeline */
  mongoc_cursor_t *cur = mongoc_collection_aggregate(col,
MONGOC_QUERY_NONE, p, NULL, NULL);
  const bson_t *d;
  while (mongoc_cursor_next(cur, &d)) {}
  if (mongoc_cursor_error(cur, &e)) printf("error: %s\n", e.message);
  return 0;
}

Expected: no error.
Actual:   error: database name "testdb.coll" invalid: contains "."

(The error is set at cursor creation, before any server I/O, so it also
reproduces without a reachable server.)

== Impact ==

Any application that uses mongoc_collection_aggregate() cannot read from
MongoDB with this package.  Discovered through the mongo_fdw foreign data
wrapper, whose reads all use aggregate, so its regression tests failed.

== Suggested fix ==

Make the definition match the declaration, in
src/libmongoc/src/mongoc/mongoc-aggregate.c:

Argh! I'm really sorry for the mistake in the patch. Thank you for
reporting this (especially for the thoroughness of your report). I will
upload a fix for this as soon as I can.

Regards,

Argh! I'm really sorry for the mistake in the patch. Thank you for
reporting this (especially for the thoroughness of your report). I will
upload a fix for this as soon as I can.

Regards,

Hello Release Team,
I am already in the process of preparing a 1.30.4-1+deb13u4 version of
mongo-c-driver to target the next point release. However, this bug
report appears to be of somewhat higher urgency. Should I upload a
1.30.4-1+deb13u4 containing only the fix for #1150302 for immediate
upload with the intent of a SUA to get the fix landed more quickly? I
would then defer the other fixes I am working on to 1.30.4-1+deb13u5.

Thanks in advance for your guidance.

Regards,

It's your call, but that sounds reasonable.

Cheers,
Emilio

Thanks. I have enough issues queued up that I would rather get this fix
out ASAP, as it the change is trivial and the problem has the potential
to impact many users.

I will make an upload today. Do I understand correctly that I simply
need to upload targeting 'trixie' then file a bug against
release.debian.org with a debdiff requesting the upload be accepted (as
for a normal SPU upload)? Is anything else required on my part for the
SUA?

Regards,

Hi Roberto,

Thank you for confirming the issue and for working on the fix.

When you get a chance, could you share a rough timeline for when the
updated package (1.30.4-1+deb13u4) might be available?

Regards,

Jeevan

On Thu, Oct 8, 2026 at 11:23 PM Roberto C. Sánchez <roberto@connexer.com> wrote:

Hi Roberto,

Thank you for confirming the issue and for working on the fix.

When you get a chance, could you share a rough timeline for when the
updated package (1.30.4-1+deb13u4) might be available?

Regards,

Jeevan

On Thu, Oct 8, 2026 at 11:23 PM Roberto C. Sánchez <roberto@connexer.com> wrote:

Hi Roberto,

Thank you for confirming the issue and for working on the fix.

When you get a chance, could you share a rough timeline for when the
updated package (1.30.4-1+deb13u4) might be available?

Regards,

Jeevan

On Thu, Oct 8, 2026 at 11:23 PM Roberto C. Sánchez <roberto@connexer.com> wrote:

Hi Jeevan,

I uploaded the package late in the evening on 9 October. The precise
timeline for acceptance is outside of my control, as it is up to the
Stable Release Managers to decide.

The bug report related to that is https://bugs.debian.org/1150479

You should subscribe to it and consider commenting there, as letting the
Stable Release Managers know that you are impacted would help them
prioritize. Additionally, the patch between the current version of the
package in trixie and the version I have proposed for upload is also
attached to that bug. As a temporary measure you could apply the patch
locally and build your own packages and use those until the offical
upload is accepted.

If you require assistance with that, please email me directly.

Regards,