Memory leaking in Eclipse Mosquitto

I was not able to add @rlight to this issue, but I'm still waiting for the information required above on this issue: vulnerability-reports#218 (comment 2545793)

assigned to @rlight

We are going to use CVE-2024-8376 for this.

added cvereserved label

mentioned in issue vulnerability-reports#218 (closed)

assigned to @romankrausfokus

marked this issue as related to vulnerability-reports#216 (closed)

marked this issue as related to vulnerability-reports#227 (closed)

changed the description

marked this issue as related to vulnerability-reports#218 (closed)

marked this issue as related to vulnerability-reports#217 (closed)

changed the description

Thank you @tiagolucas for reserving a CVE and mentioning us in the credits. Could you ideally also add our affiliation? We are all from Fraunhofer FOKUS.

In practice the credits field is a list of the credited subjects {example reference}.
We can add (Fraunhofer FOKUS) to each name if it would be your wish.

I understand. This would be fine, thank you!

Sorry @romankrausfokus I did not completely understand.
Should I add the affiliation to all names?

Yes, please @tiagolucas. We four are all from Fraunhofer FOKUS. Thanks for asking.

changed the description

Hello, as the fix has been released last week, it might be ideal to release the corresponding CVE close to that. The only piece of information which seems to be missing are the affected versions. I think @rlight is best suited to answer that. If we can support you, please let us know.

The CVE has been published, removing confidentiality from the ticket

made the issue visible to everyone

Great, thank you very much!

We are currently packaging mosquitto 2.0.20 for Debian. The above comments seem to indicate CVE-2024-8376 is fixed for that version (which is currently the latest).

@rlight We would appreciate if you could confirm that.

@rlight I'm going to close the issue as the work as been completed but non-disregarding the question by @narcminusontakac2 , which may still be answered with the issue closed.

@narcminusontakac2 That is correct

@rlight It would also b helpful to know if 2.0.11 is affected and if so which commits do fix the issue. I think we need to do a backport to 2.0.11 if so.

FYI this change applies to v2.0.11 :

https://github.com/eclipse-mosquitto/mosquitto/commit/7399ac67d1c34a243c0048856d67f87f64651df

To fix CVE-2024-8376, Is there an other worth taking from 335 commits from v2.0.11..v2.0.20 or 55 from v2.0.18..v2.0.20 ?

I am asking for Debian:

https://salsa.debian.org/debian-iot-team/mosquitto/-/merge_requests/21

added cvepublished resolutionfixed labels and removed cvereserved label

closed

@pcoval @narcminusontakac2 The commit you want is 1914b3ee2a18102d0a94cbdbbfeae1afa03edd17

You probably also want ae7a804dadac8f2aaedb24336df8496a9680fda9 and 8ab20b4ba4204fdcdec78cb4d9f03c944a6e0e1c , although they aren't related to this partiular issue.

Hi @rlight

I'm looking into backporting 1914b3 to debian and was hoping you could help me out a bit.

The current debian stable packages is based on 2.0.11 which still has test/broker/02-subpub-qos1-bad-pubcomp.py test (which was removed/replaced in 2.0.12). This test is detecting a change in behavior after applying 1914b3 commit (in how the puback response looks) which I've pinpointed to this code in src/handle_publish.c:

                        rc2 = sub__messages_queue(context->id, stored->topic, stored->qos, stored->retain, &stored);
                        /* stored may now be free, so don't refer to it */
                        if(rc2 == MOSQ_ERR_SUCCESS || context->protocol != mosq_p_mqtt5){
                                if(send__puback(context, mid, 0, NULL)) rc = 1;
                        }else if(rc2 == MOSQ_ERR_NO_SUBSCRIBERS){
                                if(send__puback(context, mid, MQTT_RC_NO_MATCHING_SUBSCRIBERS, NULL)) rc = 1;
                        }else{

Before 1914b3 the puback would be the first one ("mid, 0, NULL"), but with 1914b3 applied we get the second ("NO_SUBSCRIBERS"). In other words, the return from sub__messages_queue is different. With this change in behaviour the test/broker/02-subpub-qos1-bad-pubcomp.py says:

./02-subpub-qos1-bad-pubcomp.py
FAIL: Received incorrect puback 1s.
Received: PUBACK, rl=3, mid=1
Expected: PUBACK, rl=2, mid=1
[...]
1730460250: Sending PUBLISH to subpub-qos1-test (d0, q1, r0, m1, 'subpub/qos1', ... (7 bytes))
1730460250: Sending PUBACK to helper (m1, rc16)
1730460250: Client helper closed its connection.

(Full log at https://salsa.debian.org/rzr/mosquitto/-/jobs/6516466#L456 )

Is this expected change in behavior or not? Do you have any recommendation on how we should resolve this?

(Debian discussion is currently happening on https://salsa.debian.org/debian-iot-team/mosquitto/-/merge_requests/21 if you want to get directly involved.)

Thanks in advance.

Replying to myself, it seems the problem introduced in 1913b3 is fixed in b979feb92aa5b22d557b3e60cc191ba18755558e

Hi I confirm we have a serie of patches that applies debian stable version that pass debian CI testing (autopkgtest).

To help/enable a security upload, please can upstream be involved in the review at:

https://salsa.debian.org/debian-iot-team/mosquitto/-/merge_requests/21

If is it too cumbersome, I can provide you a list of cherry-picked patches.

Regards

cc: @andhe

Memory leaking in Eclipse Mosquitto

Basic information

Child items ...

Activity

Memory leaking in Eclipse Mosquitto

Basic information

Relates to

Activity