1788543 - AddressSanitizer: heap-use-after-free [@ strcmp] with READ of size 1 through [@ nsPrinterCUPS::TryEnsurePrinterInfo]

Status: RESOLVED INCOMPLETE

(Core :: Printing: Setup, defect)

Description

[Christian Holler (:decoder)]

The attached crash information was submitted via the ASan Nightly Reporter on mozilla-central-asan-nightly revision 106.0a1-20220831093258-https://hg.mozilla.org/mozilla-central/rev/11e997d3cf78eb6a4f31a1e13a2509f4181f4b0a.

For detailed crash information, see attachment.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Andrew McCreight [:mccr8]]

It looks like this is inside CUPS code so I don't know how actionable it is.

Emily, it looks like you've done some work in nsPrinterCUPS.cpp recently. Do you have any ideas about what we might be able to do for this? Thanks.

Comment 3

[Emily McDonough [:alaskanemily]]

I'll take a look at this and see if I can figure anything out.

Comment 4

[Emily McDonough [:alaskanemily]]

OK, I looked into this. Unfortunately, though the stacktrace looks valid, I don't think it helps us track down the exact issue beyond having some issue with memory management and CUPS. I believe that either this is the result of unrelated memory corruption that happened to hit the CUPS string table, or (more likely to me) this is a real issue with our usage of CUPS but this stacktrace occurs during a later call into CUPS code, and not the call that caused the problem.

Unfortunately this stacktrace doesn't indicate enough information about the CUPS configuration for me to really diagnose anything specific at this point. It's possible this is in some way related to the implied crashes with Firefox using a remote CUPS server, or this could be a new issue.

There were some concerns that CUPS code may have race conditions in its string table code, but after looking through it I think it's pretty carefully implemented to lock the string table with a mutex for any accesses and so I don't think this is the cause.

(Leaving my ni because I want to investigate further with a local ASAN build and see if I can reproduce this issue locally)

Comment 5

[Andrew McCreight [:mccr8]]

I'll mark this sec-vector.

Comment 6

[Daniel Holbert [:dholbert]]

(RE 'regression' keyword: we don't strictly know that this is a regression; we've just gotten a single report and that's the only info we have, really.)

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Emily McDonough [:alaskanemily] from comment #4)

(Leaving my ni because I want to investigate further with a local ASAN build and see if I can reproduce this issue locally)

Did you get around to this?

(In reply to Christian Holler (:decoder) from comment #0)

The attached crash information was submitted via the ASan Nightly Reporter

Given we only have this one data-point, and there's external software / tooling involved (CUPS / printers), this might end up being stalled/dunno. (Emily investigated pretty thoroughly in comment 4, modulo the pending needinfo, and it sounds like we're a bit stumped.)

Comment 8

[Daniel Holbert [:dholbert]]

Calling this stalled and downgrading to S3 at the moment, per end of comment 7.

Comment 9

[Tom Ritter [:tjr] (OOTO until 7/21)]

Resolving stalled bugs we don't have ongoing issues with or a path forward on.

Comment 10

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit BugBot documentation.