ghsa-3wf5-cgv3-f3xm
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: re-fix fortified-memset warning
The carl9170_tx_release() function sometimes triggers a fortified-memset warning in my randconfig builds:
In file included from include/linux/string.h:254, from drivers/net/wireless/ath/carl9170/tx.c:40: In function 'fortify_memset_chk', inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2, inlined from 'kref_put' at include/linux/kref.h:65:3, inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 493 | __write_overflow_field(p_size_field, size);
Kees previously tried to avoid this by using memset_after(), but it seems this does not fully address the problem. I noticed that the memset_after() here is done on a different part of the union (status) than the original cast was from (rate_driver_data), which may confuse the compiler.
Unfortunately, the memset_after() trick does not work on driver_rates[] because that is part of an anonymous struct, and I could not get struct_group() to do this either. Using two separate memset() calls on the two members does address the warning though.
{ "affected": [], "aliases": [ "CVE-2024-38616" ], "database_specific": { "cwe_ids": [ "CWE-400" ], "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-06-19T14:15:21Z", "severity": "HIGH" }, "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: carl9170: re-fix fortified-memset warning\n\nThe carl9170_tx_release() function sometimes triggers a fortified-memset\nwarning in my randconfig builds:\n\nIn file included from include/linux/string.h:254,\n from drivers/net/wireless/ath/carl9170/tx.c:40:\nIn function \u0027fortify_memset_chk\u0027,\n inlined from \u0027carl9170_tx_release\u0027 at drivers/net/wireless/ath/carl9170/tx.c:283:2,\n inlined from \u0027kref_put\u0027 at include/linux/kref.h:65:3,\n inlined from \u0027carl9170_tx_put_skb\u0027 at drivers/net/wireless/ath/carl9170/tx.c:342:9:\ninclude/linux/fortify-string.h:493:25: error: call to \u0027__write_overflow_field\u0027 declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]\n 493 | __write_overflow_field(p_size_field, size);\n\nKees previously tried to avoid this by using memset_after(), but it seems\nthis does not fully address the problem. I noticed that the memset_after()\nhere is done on a different part of the union (status) than the original\ncast was from (rate_driver_data), which may confuse the compiler.\n\nUnfortunately, the memset_after() trick does not work on driver_rates[]\nbecause that is part of an anonymous struct, and I could not get\nstruct_group() to do this either. Using two separate memset() calls\non the two members does address the warning though.", "id": "GHSA-3wf5-cgv3-f3xm", "modified": "2024-07-03T18:45:58Z", "published": "2024-06-19T15:30:54Z", "references": [ { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38616" }, { "type": "WEB", "url": "https://git.kernel.org/stable/c/042a39bb8e0812466327a5102606e88a5a4f8c02" }, { "type": "WEB", "url": "https://git.kernel.org/stable/c/066afafc10c9476ee36c47c9062527a17e763901" }, { "type": "WEB", "url": "https://git.kernel.org/stable/c/0c38c9c460bb8ce8d6f6cf316e0d71a70983ec83" }, { "type": "WEB", "url": "https://git.kernel.org/stable/c/13857683126e8a6492af73c74d702835f7a2175b" }, { "type": "WEB", "url": "https://git.kernel.org/stable/c/87586467098281f04fa93e59fe3a516b954bddc4" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H", "type": "CVSS_V3" } ] }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.