Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #86950 > unrolled thread

CVE-2025-2312 in cifs-utils

Started byNoah Meyerhans <noahm@debian.org>
First post2025-04-22 19:50 +0200
Last post2025-05-20 10:30 +0200
Articles 5 — 2 participants

Back to article view | Back to linux.debian.kernel


Contents

  CVE-2025-2312 in cifs-utils Noah Meyerhans <noahm@debian.org> - 2025-04-22 19:50 +0200
    Re: CVE-2025-2312 in cifs-utils Salvatore Bonaccorso <carnil@debian.org> - 2025-04-22 20:00 +0200
      Re: CVE-2025-2312 in cifs-utils Noah Meyerhans <noahm@debian.org> - 2025-04-22 20:20 +0200
        Re: CVE-2025-2312 in cifs-utils Salvatore Bonaccorso <carnil@debian.org> - 2025-04-22 21:10 +0200
          Re: CVE-2025-2312 in cifs-utils Salvatore Bonaccorso <carnil@debian.org> - 2025-05-20 10:30 +0200

#86950 — CVE-2025-2312 in cifs-utils

FromNoah Meyerhans <noahm@debian.org>
Date2025-04-22 19:50 +0200
SubjectCVE-2025-2312 in cifs-utils
Message-ID<KEpUS-fsNT-9@gated-at.bofh.it>
My employer is interested in seeing cifs-utils CVE-2025-2312
(cifs.upcall program from the cifs-utils package makes an upcall to the
wrong namespace in containerized environments) fixed in bookworm. [1]
According to the tracker, the fix depends on a kernel change in addition
to the cifs-utils userspace fix [2, 3].

The kernel change doesn't appear to have been backported to any of the
kernel.org LTS trees, so I've suggested that the people responsible for
implementation of that change should also work to backport it there.
Without this, it seems that even trixie will be vulnerable.

I don't believe that this issue warrants a DSA, or that it should be
considered RC for trixie.  If we publish a fix, it should be by way of a
point release containing a kernel that includes the upstream change and
an updated cifs-utils package.  Do the maintainers involved agree?

In the event that upstream is unwilling to apply this change to the
kernel LTS trees, would the kernel team consider carrying it as a local
patch?

Thanks
noah

1. https://security-tracker.debian.org/tracker/CVE-2025-2312
2. https://git.kernel.org/linus/db363b0a1d9e6b9dc556296f1b1007aeb496a8cf
3. https://git.samba.org/?p=cifs-utils.git;a=commit;h=89b679228cc1be9739d54203d28289b03352c174

[toc] | [next] | [standalone]


#86951

FromSalvatore Bonaccorso <carnil@debian.org>
Date2025-04-22 20:00 +0200
Message-ID<KEq4x-fsRL-1@gated-at.bofh.it>
In reply to#86950
Hi Noah,

On Tue, Apr 22, 2025 at 01:49:39PM -0400, Noah Meyerhans wrote:
> My employer is interested in seeing cifs-utils CVE-2025-2312
> (cifs.upcall program from the cifs-utils package makes an upcall to the
> wrong namespace in containerized environments) fixed in bookworm. [1]
> According to the tracker, the fix depends on a kernel change in addition
> to the cifs-utils userspace fix [2, 3].
> 
> The kernel change doesn't appear to have been backported to any of the
> kernel.org LTS trees, so I've suggested that the people responsible for
> implementation of that change should also work to backport it there.
> Without this, it seems that even trixie will be vulnerable.
> 
> I don't believe that this issue warrants a DSA, or that it should be
> considered RC for trixie.  If we publish a fix, it should be by way of a
> point release containing a kernel that includes the upstream change and
> an updated cifs-utils package.  Do the maintainers involved agree?

Speaking for the security-team, right the issue does not warrant a DSA
on its own, it might be addressed in a point release (and have it
already prepared in the occurence of using a kernel with the kernel
side fix). I cannot speak though for the cifs-utils maintainers.
> 
> In the event that upstream is unwilling to apply this change to the
> kernel LTS trees, would the kernel team consider carrying it as a local
> patch?

Speaking for the kernel-team: No, if we want that change in stable and
for the 6.1.y kernel then it should be accepted upstream in the 6.1.y
series. As alternative your employer might use backports kernel?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]


#86952

FromNoah Meyerhans <noahm@debian.org>
Date2025-04-22 20:20 +0200
Message-ID<KEqnT-ftek-1@gated-at.bofh.it>
In reply to#86951
On Tue, Apr 22, 2025 at 07:58:56PM +0200, Salvatore Bonaccorso wrote:
> Speaking for the kernel-team: No, if we want that change in stable and
> for the 6.1.y kernel then it should be accepted upstream in the 6.1.y
> series. As alternative your employer might use backports kernel?

The kernel change was introduced with 6.13, so backports doesn't help
yet.  I'll work with my employer's kernel folkѕ on getting the kernel
change applied to the 6.x LTS branches, and will revisit this with the
cifs-utils maintainers once it's available there.

Thanks
noah

[toc] | [prev] | [next] | [standalone]


#86953

FromSalvatore Bonaccorso <carnil@debian.org>
Date2025-04-22 21:10 +0200
Message-ID<KErai-ftLq-1@gated-at.bofh.it>
In reply to#86952
Hi Noah,

On Tue, Apr 22, 2025 at 02:16:04PM -0400, Noah Meyerhans wrote:
> On Tue, Apr 22, 2025 at 07:58:56PM +0200, Salvatore Bonaccorso wrote:
> > Speaking for the kernel-team: No, if we want that change in stable and
> > for the 6.1.y kernel then it should be accepted upstream in the 6.1.y
> > series. As alternative your employer might use backports kernel?
> 
> The kernel change was introduced with 6.13, so backports doesn't help
> yet.  I'll work with my employer's kernel folkѕ on getting the kernel
> change applied to the 6.x LTS branches, and will revisit this with the
> cifs-utils maintainers once it's available there.

Just for clarity, yes I know, the target kernel for trixie will be
6.12.y based, what i meant is once we have backports there. Sorry that
I was not clear about it.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]


#87621

FromSalvatore Bonaccorso <carnil@debian.org>
Date2025-05-20 10:30 +0200
Message-ID<KOqwh-4p8n-1@gated-at.bofh.it>
In reply to#86953
Hi Noah,

On Tue, Apr 22, 2025 at 09:03:16PM +0200, Salvatore Bonaccorso wrote:
> Hi Noah,
> 
> On Tue, Apr 22, 2025 at 02:16:04PM -0400, Noah Meyerhans wrote:
> > On Tue, Apr 22, 2025 at 07:58:56PM +0200, Salvatore Bonaccorso wrote:
> > > Speaking for the kernel-team: No, if we want that change in stable and
> > > for the 6.1.y kernel then it should be accepted upstream in the 6.1.y
> > > series. As alternative your employer might use backports kernel?
> > 
> > The kernel change was introduced with 6.13, so backports doesn't help
> > yet.  I'll work with my employer's kernel folkѕ on getting the kernel
> > change applied to the 6.x LTS branches, and will revisit this with the
> > cifs-utils maintainers once it's available there.
> 
> Just for clarity, yes I know, the target kernel for trixie will be
> 6.12.y based, what i meant is once we have backports there. Sorry that
> I was not clear about it.

FYI: https://bugs.debian.org/1105747 for the cifs-utils side.

The commit got queued for the 6.12.y series:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=7294cf6ff42482531f62f9b2a74d9c7ee00bbb59

Regards,
Salvatore

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web