admin/nvd-json-data-feeds
1
0
Fork 0
mirror of https://github.com/fkie-cad/nvd-json-data-feeds.git synced 2025-06-19 17:31:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

Auto-Update: 2025-05-02T14:00:21.284315+00:00

Browse Source
This commit is contained in:
cad-safe-bot 2025-05-02 14:03:57 +00:00
parent 5a4f6b72a9
commit ea2d0aa18a
618 changed files with 4133 additions and 1890 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
CVE-2006/CVE-2006-51xx/CVE-2006-5175.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2006-5175",
"sourceIdentifier": "cve@mitre.org",
"published": "2006-10-10T04:06:00.000",
"lastModified": "2025-05-01T19:57:49.380",
"vulnStatus": "Undergoing Analysis",
"lastModified": "2025-05-02T12:11:52.183",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
{
@ -63,8 +63,9 @@
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:h:buffalotech:terastation_hd-htgl_firmware:2.05_beta1:*:*:*:*:*:*:*",
"matchCriteriaId": "15462754-3599-4F4B-B139-26472CC4BDA2"
"criteria": "cpe:2.3:o:buffalo-technology:terastation_hd-htgl_firmware:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.08",
"matchCriteriaId": "4345AAD8-45CC-4459-A2D0-B6E4B695A5A3"
}
]
}
@ -74,41 +75,59 @@
"references": [
{
"url": "http://jvn.jp/jp/JVN%2393484133/index.html",
"source": "cve@mitre.org"
"source": "cve@mitre.org",
"tags": [
"Third Party Advisory"
]
},
{
"url": "http://secunia.com/advisories/22248",
"source": "cve@mitre.org",
"tags": [
"Vendor Advisory"
"Third Party Advisory"
]
},
{
"url": "http://www.vupen.com/english/advisories/2006/3891",
"source": "cve@mitre.org"
"source": "cve@mitre.org",
"tags": [
"Broken Link"
]
},
{
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/29338",
"source": "cve@mitre.org"
"source": "cve@mitre.org",
"tags": [
"Third Party Advisory"
]
},
{
"url": "http://jvn.jp/jp/JVN%2393484133/index.html",
"source": "af854a3a-2127-422b-91ae-364da2661108"
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Third Party Advisory"
]
},
{
"url": "http://secunia.com/advisories/22248",
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Vendor Advisory"
"Third Party Advisory"
]
},
{
"url": "http://www.vupen.com/english/advisories/2006/3891",
"source": "af854a3a-2127-422b-91ae-364da2661108"
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Broken Link"
]
},
{
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/29338",
"source": "af854a3a-2127-422b-91ae-364da2661108"
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Third Party Advisory"
]
}
]
}

4
CVE-2020/CVE-2020-367xx/CVE-2020-36790.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2020-36790",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:15:54.020",
"lastModified": "2025-05-01T15:15:54.020",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

8
CVE-2022/CVE-2022-275xx/CVE-2022-27562.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-27562",
"sourceIdentifier": "psirt@hcl.com",
"published": "2025-04-30T21:15:52.303",
"lastModified": "2025-04-30T21:15:52.303",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:40.163",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Unsafe default file type filter policy in HCL Domino Volt allows upload of .html file and execution of unsafe JavaScript in deployed applications."
},
{
"lang": "es",
"value": "La pol\u00edtica de filtro de tipo de archivo predeterminado no seguro en HCL Domino Volt permite la carga de archivos .html y la ejecuci\u00f3n de JavaScript no seguro en aplicaciones implementadas."
}
],
"metrics": {

4
CVE-2022/CVE-2022-393xx/CVE-2022-39393.json
View File

@ -2,13 +2,13 @@
"id": "CVE-2022-39393",
"sourceIdentifier": "security-advisories@github.com",
"published": "2022-11-10T20:15:11.520",
"lastModified": "2024-11-21T07:18:11.957",
"lastModified": "2025-05-02T13:15:45.630",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Wasmtime is a standalone runtime for WebAssembly. Prior to version 2.0.2, there is a bug in Wasmtime's implementation of its pooling instance allocator where when a linear memory is reused for another instance the initial heap snapshot of the prior instance can be visible, erroneously to the next instance. This bug has been patched and users should upgrade to Wasmtime 2.0.2. Other mitigations include disabling the pooling allocator and disabling the `memory-init-cow`."
"value": "Wasmtime is a standalone runtime for WebAssembly. Prior to versions 2.0.2 and 1.0.2, there is a bug in Wasmtime's implementation of its pooling instance allocator where when a linear memory is reused for another instance the initial heap snapshot of the prior instance can be visible, erroneously to the next instance. This bug has been patched and users should upgrade to Wasmtime 2.0.2 and 1.0.2. Other mitigations include disabling the pooling allocator and disabling the `memory-init-cow`."
},
{
"lang": "es",

8
CVE-2022/CVE-2022-424xx/CVE-2022-42449.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-42449",
"sourceIdentifier": "psirt@hcl.com",
"published": "2025-04-30T21:15:53.053",
"lastModified": "2025-04-30T21:15:53.053",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:40.163",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Unsafe default file type filter policy in HCL Domino Volt allows upload of .html file and execution of unsafe JavaScript in deployed applications"
},
{
"lang": "es",
"value": "La pol\u00edtica de filtro de tipo de archivo predeterminado no seguro en HCL Domino Volt permite la carga de archivos .html y la ejecuci\u00f3n de JavaScript no seguro en aplicaciones implementadas"
}
],
"metrics": {

8
CVE-2022/CVE-2022-424xx/CVE-2022-42450.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-42450",
"sourceIdentifier": "psirt@hcl.com",
"published": "2025-04-30T22:15:15.083",
"lastModified": "2025-04-30T22:15:15.083",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:40.163",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Improper sanitization of SVG files in HCL Domino Volt allows client-side script injection in deployed applications."
},
{
"lang": "es",
"value": "La depuraci\u00f3n inadecuada de archivos SVG en HCL Domino Volt permite client-side script injection en aplicaciones implementadas."
}
],
"metrics": {

4
CVE-2022/CVE-2022-497xx/CVE-2022-49762.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49762",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:15:58.933",
"lastModified": "2025-05-01T15:15:58.933",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49763.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49763",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:15:59.047",
"lastModified": "2025-05-01T15:15:59.047",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49764.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49764",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:15:59.170",
"lastModified": "2025-05-01T15:15:59.170",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49765.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49765",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:15:59.277",
"lastModified": "2025-05-01T15:15:59.277",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49766.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49766",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:15:59.380",
"lastModified": "2025-05-01T15:15:59.380",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49767.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49767",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:15:59.483",
"lastModified": "2025-05-01T15:15:59.483",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49768.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49768",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:15:59.597",
"lastModified": "2025-05-01T15:15:59.597",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49769.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49769",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:15:59.710",
"lastModified": "2025-05-01T15:15:59.710",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49770.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49770",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:15:59.920",
"lastModified": "2025-05-01T15:15:59.920",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49771.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49771",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:00.237",
"lastModified": "2025-05-01T15:16:00.237",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49772.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49772",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:00.347",
"lastModified": "2025-05-01T15:16:00.347",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49773.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49773",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:00.453",
"lastModified": "2025-05-01T15:16:00.453",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49774.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49774",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:00.557",
"lastModified": "2025-05-01T15:16:00.557",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49775.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49775",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:00.650",
"lastModified": "2025-05-01T15:16:00.650",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49776.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49776",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:00.763",
"lastModified": "2025-05-01T15:16:00.763",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49777.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49777",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:00.870",
"lastModified": "2025-05-01T15:16:00.870",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49778.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49778",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:00.980",
"lastModified": "2025-05-01T15:16:00.980",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49779.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49779",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:01.080",
"lastModified": "2025-05-01T15:16:01.080",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49780.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49780",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:01.200",
"lastModified": "2025-05-01T15:16:01.200",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49781.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49781",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:01.307",
"lastModified": "2025-05-01T15:16:01.307",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49782.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49782",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:01.410",
"lastModified": "2025-05-01T15:16:01.410",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49783.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49783",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:01.510",
"lastModified": "2025-05-01T15:16:01.510",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49784.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49784",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:01.610",
"lastModified": "2025-05-01T15:16:01.610",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49785.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49785",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:01.713",
"lastModified": "2025-05-01T15:16:01.713",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49786.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49786",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:01.813",
"lastModified": "2025-05-01T15:16:01.813",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49787.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49787",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:01.920",
"lastModified": "2025-05-01T15:16:01.920",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49788.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49788",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:02.027",
"lastModified": "2025-05-01T15:16:02.027",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49789.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49789",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:02.143",
"lastModified": "2025-05-01T15:16:02.143",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49790.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49790",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:02.260",
"lastModified": "2025-05-01T15:16:02.260",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2022/CVE-2022-497xx/CVE-2022-49791.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-49791",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:02.367",
"lastModified": "2025-05-01T15:16:02.367",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{

8
CVE-2022/CVE-2022-497xx/CVE-2022-49792.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49792",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:02.460",
"lastModified": "2025-05-01T15:16:02.460",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: mp2629: fix potential array out of bound access\n\nAdd sentinel at end of maps to avoid potential array out of\nbound access in iio core."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: mp2629: se corrige un posible acceso fuera de los l\u00edmites de la matriz. Se agrega centinela al final de los mapas para evitar un posible acceso fuera de los l\u00edmites de la matriz en el n\u00facleo iio."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-497xx/CVE-2022-49793.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49793",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:02.563",
"lastModified": "2025-05-01T15:16:02.563",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init()\n\ndev_set_name() allocates memory for name, it need be freed\nwhen device_add() fails, call put_device() to give up the\nreference that hold in device_initialize(), so that it can\nbe freed in kobject_cleanup() when the refcount hit to 0.\n\nFault injection test can trigger this:\n\nunreferenced object 0xffff8e8340a7b4c0 (size 32):\n comm \"modprobe\", pid 243, jiffies 4294678145 (age 48.845s)\n hex dump (first 32 bytes):\n 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge\n 72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............\n backtrace:\n [<0000000074999de8>] __kmem_cache_alloc_node+0x1e9/0x360\n [<00000000497fd30b>] __kmalloc_node_track_caller+0x44/0x1a0\n [<000000003636c520>] kstrdup+0x2d/0x60\n [<0000000032f84da2>] kobject_set_name_vargs+0x1e/0x90\n [<0000000092efe493>] dev_set_name+0x4e/0x70"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: trigger: sysfs: se corrige una posible fuga de memoria en iio_sysfs_trig_init(). dev_set_name() asigna memoria para name. Esta debe liberarse cuando device_add() falla. Se llama a put_device() para liberar la referencia contenida en device_initialize(), de modo que pueda liberarse en kobject_cleanup() cuando refcount llegue a 0. La prueba de inyecci\u00f3n de fallos puede desencadenar esto: objeto sin referencia 0xffff8e8340a7b4c0 (tama\u00f1o 32): comm \"modprobe\", pid 243, jiffies 4294678145 (edad 48.845s) volcado hexadecimal (primeros 32 bytes): 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge 72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............ backtrace: [&lt;0000000074999de8&gt;] __kmem_cache_alloc_node+0x1e9/0x360 [&lt;00000000497fd30b&gt;] __kmalloc_node_track_caller+0x44/0x1a0 [&lt;000000003636c520&gt;] kstrdup+0x2d/0x60 [&lt;0000000032f84da2&gt;] kobject_set_name_vargs+0x1e/0x90 [&lt;0000000092efe493&gt;] dev_set_name+0x4e/0x70 "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-497xx/CVE-2022-49794.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49794",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:02.673",
"lastModified": "2025-05-01T15:16:02.673",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger()\n\nIf iio_trigger_register() returns error, it should call iio_trigger_free()\nto give up the reference that hold in iio_trigger_alloc(), so that it can\ncall iio_trig_release() to free memory when the refcount hit to 0."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: at91_adc: corrige posible p\u00e9rdida de memoria en at91_adc_allocate_trigger() Si iio_trigger_register() devuelve un error, debe llamar a iio_trigger_free() para renunciar a la referencia contenida en iio_trigger_alloc(), de modo que pueda llamar a iio_trig_release() para liberar memoria cuando el recuento de referencias llegue a 0."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-497xx/CVE-2022-49795.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49795",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:02.783",
"lastModified": "2025-05-01T15:16:02.783",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrethook: fix a potential memleak in rethook_alloc()\n\nIn rethook_alloc(), the variable rh is not freed or passed out\nif handler is NULL, which could lead to a memleak, fix it.\n\n[Masami: Add \"rethook:\" tag to the title.]\n\nAcke-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rethook: se corrige una posible fuga de memoria en rethook_alloc(). En rethook_alloc(), la variable rh no se libera ni se pasa si el manejador es NULL, lo que podr\u00eda provocar una fuga de memoria. Corr\u00edjalo. [Masami: A\u00f1adir la etiqueta \"rethook:\" al t\u00edtulo]. Por: Masami Hiramatsu (Google) "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-497xx/CVE-2022-49796.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49796",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:02.887",
"lastModified": "2025-05-01T15:16:02.887",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: kprobe: Fix potential null-ptr-deref on trace_array in kprobe_event_gen_test_exit()\n\nWhen test_gen_kprobe_cmd() failed after kprobe_event_gen_cmd_end(), it\nwill goto delete, which will call kprobe_event_delete() and release the\ncorresponding resource. However, the trace_array in gen_kretprobe_test\nwill point to the invalid resource. Set gen_kretprobe_test to NULL\nafter called kprobe_event_delete() to prevent null-ptr-deref.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000070\nPGD 0 P4D 0\nOops: 0000 [#1] SMP PTI\nCPU: 0 PID: 246 Comm: modprobe Tainted: G W\n6.1.0-rc1-00174-g9522dc5c87da-dirty #248\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0\nCode: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c\n01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 <44> 8b 65\n70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f\nRSP: 0018:ffffc9000159fe00 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000\nRDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001\nR10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064\nR13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000\nFS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n __ftrace_set_clr_event+0x3e/0x60\n trace_array_set_clr_event+0x35/0x50\n ? 0xffffffffa0000000\n kprobe_event_gen_test_exit+0xcd/0x10b [kprobe_event_gen_test]\n __x64_sys_delete_module+0x206/0x380\n ? lockdep_hardirqs_on_prepare+0xd8/0x190\n ? syscall_enter_from_user_mode+0x1c/0x50\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f89eeb061b7"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: kprobe: Se corrige la posible desreferencia de PTR nula en trace_array en kprobe_event_gen_test_exit(). Cuando test_gen_kprobe_cmd() falla despu\u00e9s de kprobe_event_gen_cmd_end(), se ejecuta el comando \"eliminar\", lo que llama a kprobe_event_delete() y libera el recurso correspondiente. Sin embargo, trace_array en gen_kretprobe_test apuntar\u00e1 al recurso no v\u00e1lido. Establezca gen_kretprobe_test en NULL despu\u00e9s de llamar a kprobe_event_delete() para evitar la desreferencia de PTR nula. ERROR: desreferencia de puntero NULL del n\u00facleo, direcci\u00f3n: 0000000000000070 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 246 Comm: modprobe Tainted: GW 6.1.0-rc1-00174-g9522dc5c87da-dirty #248 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0 Code: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c 01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 &lt;44&gt; 8b 65 70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f RSP: 0018:ffffc9000159fe00 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000 RDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064 R13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000 FS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __ftrace_set_clr_event+0x3e/0x60 trace_array_set_clr_event+0x35/0x50 ? 0xffffffffa0000000 kprobe_event_gen_test_exit+0xcd/0x10b [kprobe_event_gen_test] __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f89eeb061b7 "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-497xx/CVE-2022-49797.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49797",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:02.990",
"lastModified": "2025-05-01T15:16:02.990",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: kprobe: Fix potential null-ptr-deref on trace_event_file in kprobe_event_gen_test_exit()\n\nWhen trace_get_event_file() failed, gen_kretprobe_test will be assigned\nas the error code. If module kprobe_event_gen_test is removed now, the\nnull pointer dereference will happen in kprobe_event_gen_test_exit().\nCheck if gen_kprobe_test or gen_kretprobe_test is error code or NULL\nbefore dereference them.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\nPGD 0 P4D 0\nOops: 0000 [#1] SMP PTI\nCPU: 3 PID: 2210 Comm: modprobe Not tainted\n6.1.0-rc1-00171-g2159299a3b74-dirty #217\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test]\nCode: Unable to access opcode bytes at 0xffffffff9ffffff2.\nRSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246\nRAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 0000000000000000\nRDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c\nRBP: ffffffffa0000000 R08: 0000000000000004 R09: 00000000001e95c0\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000800\nR13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000\nFS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n __x64_sys_delete_module+0x206/0x380\n ? lockdep_hardirqs_on_prepare+0xd8/0x190\n ? syscall_enter_from_user_mode+0x1c/0x50\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: kprobe: Se corrige la posible desreferencia de puntero nulo en trace_event_file en kprobe_event_gen_test_exit(). Cuando trace_get_event_file() falla, se asigna gen_kretprobe_test como c\u00f3digo de error. Si se elimina el m\u00f3dulo kprobe_event_gen_test, se producir\u00e1 la desreferencia de puntero nulo en kprobe_event_gen_test_exit(). Compruebe si gen_kprobe_test o gen_kretprobe_test son c\u00f3digos de error o nulos antes de desreferenciarlos. ERROR: desreferencia de puntero NULL del n\u00facleo, direcci\u00f3n: 0000000000000012 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 2210 Comm: modprobe No contaminado 6.1.0-rc1-00171-g2159299a3b74-dirty #217 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test] C\u00f3digo: No se puede acceder a los bytes del c\u00f3digo de operaci\u00f3n en 0xffffffff9ffffff2. RSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246 RAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 000000000000000 RDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c RBP: ffffffffa0000000 R08: 000000000000004 R09: 00000000001e95c0 R10: 000000000000000 R11: 000000000000001 R12: 0000000000000800 R13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 000000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-497xx/CVE-2022-49798.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49798",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:03.097",
"lastModified": "2025-05-01T15:16:03.097",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix race where eprobes can be called before the event\n\nThe flag that tells the event to call its triggers after reading the event\nis set for eprobes after the eprobe is enabled. This leads to a race where\nthe eprobe may be triggered at the beginning of the event where the record\ninformation is NULL. The eprobe then dereferences the NULL record causing\na NULL kernel pointer bug.\n\nTest for a NULL record to keep this from happening."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Se corrige la ejecuci\u00f3n donde se pueden llamar los eprobes antes del evento. El indicador que indica al evento que llame a sus desencadenadores despu\u00e9s de leer el evento se establece para los eprobes despu\u00e9s de habilitarlos. Esto provoca una ejecuci\u00f3n donde el eprobe puede activarse al inicio del evento cuando la informaci\u00f3n del registro es nula. El eprobe entonces desreferencia el registro nulo, causando un error de puntero de kernel nulo. Pruebe si hay un registro nulo para evitar que esto suceda."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-497xx/CVE-2022-49799.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49799",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:03.200",
"lastModified": "2025-05-01T15:16:03.200",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix wild-memory-access in register_synth_event()\n\nIn register_synth_event(), if set_synth_event_print_fmt() failed, then\nboth trace_remove_event_call() and unregister_trace_event() will be\ncalled, which means the trace_event_call will call\n__unregister_trace_event() twice. As the result, the second unregister\nwill causes the wild-memory-access.\n\nregister_synth_event\n set_synth_event_print_fmt failed\n trace_remove_event_call\n event_remove\n if call->event.funcs then\n __unregister_trace_event (first call)\n unregister_trace_event\n __unregister_trace_event (second call)\n\nFix the bug by avoiding to call the second __unregister_trace_event() by\nchecking if the first one is called.\n\ngeneral protection fault, probably for non-canonical address\n\t0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI\nKASAN: maybe wild-memory-access in range\n[0xdead000000000120-0xdead000000000127]\nCPU: 0 PID: 3807 Comm: modprobe Not tainted\n6.1.0-rc1-00186-g76f33a7eedb4 #299\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:unregister_trace_event+0x6e/0x280\nCode: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48\nb8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02\n00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b\nRSP: 0018:ffff88810413f370 EFLAGS: 00010a06\nRAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000\nRDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20\nRBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481\nR10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122\nR13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028\nFS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n __create_synth_event+0x1e37/0x1eb0\n create_or_delete_synth_event+0x110/0x250\n synth_event_run_command+0x2f/0x110\n test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test]\n synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test]\n do_one_initcall+0xdb/0x480\n do_init_module+0x1cf/0x680\n load_module+0x6a50/0x70a0\n __do_sys_finit_module+0x12f/0x1c0\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Se corrige el acceso a memoria no autorizado en register_synth_event(). En register_synth_event(), si set_synth_event_print_fmt() falla, se invocar\u00e1n trace_remove_event_call() y unregister_trace_event(), lo que significa que trace_event_call llamar\u00e1 a __unregister_trace_event() dos veces. Como resultado, la segunda anulaci\u00f3n del registro provocar\u00e1 el acceso a memoria no autorizado. register_synth_event set_synth_event_print_fmt fall\u00f3 trace_remove_event_call event_remove si call-&gt;event.funcs entonces __unregister_trace_event (primera llamada) unregister_trace_event __unregister_trace_event (segunda llamada) Corrija el error evitando llamar al segundo __unregister_trace_event() verificando si se llama al primero. Fallo de protecci\u00f3n general, probablemente por direcci\u00f3n no can\u00f3nica 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI KASAN: tal vez acceso a memoria salvaje en el rango [0xdead000000000120-0xdead000000000127] CPU: 0 PID: 3807 Comm: modprobe No contaminado 6.1.0-rc1-00186-g76f33a7eedb4 #299 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_trace_event+0x6e/0x280 C\u00f3digo: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b RSP: 0018:ffff88810413f370 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 RBP: muerto000000000100 R08: 0000000000000000 R09: ffffbfff0913481 R10: ffffffff8489a407 R11: ffffbfff0913480 R12: muerto000000000122 R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: __create_synth_event+0x1e37/0x1eb0 create_or_delete_synth_event+0x110/0x250 synth_event_run_command+0x2f/0x110 test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49800.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49800",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:03.303",
"lastModified": "2025-05-01T15:16:03.303",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()\n\ntest_gen_synth_cmd() only free buf in fail path, hence buf will leak\nwhen there is no failure. Add kfree(buf) to prevent the memleak. The\nsame reason and solution in test_empty_synth_event().\n\nunreferenced object 0xffff8881127de000 (size 2048):\n comm \"modprobe\", pid 247, jiffies 4294972316 (age 78.756s)\n hex dump (first 32 bytes):\n 20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test\n 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_\n backtrace:\n [<000000004254801a>] kmalloc_trace+0x26/0x100\n [<0000000039eb1cf5>] 0xffffffffa00083cd\n [<000000000e8c3bc8>] 0xffffffffa00086ba\n [<00000000c293d1ea>] do_one_initcall+0xdb/0x480\n [<00000000aa189e6d>] do_init_module+0x1cf/0x680\n [<00000000d513222b>] load_module+0x6a50/0x70a0\n [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0\n [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90\n [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\nunreferenced object 0xffff8881127df000 (size 2048):\n comm \"modprobe\", pid 247, jiffies 4294972324 (age 78.728s)\n hex dump (first 32 bytes):\n 20 65 6d 70 74 79 5f 73 79 6e 74 68 5f 74 65 73 empty_synth_tes\n 74 20 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 t pid_t next_pi\n backtrace:\n [<000000004254801a>] kmalloc_trace+0x26/0x100\n [<00000000d4db9a3d>] 0xffffffffa0008071\n [<00000000c31354a5>] 0xffffffffa00086ce\n [<00000000c293d1ea>] do_one_initcall+0xdb/0x480\n [<00000000aa189e6d>] do_init_module+0x1cf/0x680\n [<00000000d513222b>] load_module+0x6a50/0x70a0\n [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0\n [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90\n [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Se corrige la fuga de memoria en test_gen_synth_cmd() y test_empty_synth_event(). Test_gen_synth_cmd() solo libera b\u00fafer en la ruta de fallo, por lo que el b\u00fafer se filtrar\u00e1 aunque no haya fallo. Se ha a\u00f1adido kfree(buf) para evitar la fuga de memoria. La misma raz\u00f3n y soluci\u00f3n se aplican en test_empty_synth_event(). objeto sin referencia 0xffff8881127de000 (size 2048): comm \"modprobe\", pid 247, jiffies 4294972316 (age 78.756s) hex dump (first 32 bytes): 20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_ backtrace: [&lt;000000004254801a&gt;] kmalloc_trace+0x26/0x100 [&lt;0000000039eb1cf5&gt;] 0xffffffffa00083cd [&lt;000000000e8c3bc8&gt;] 0xffffffffa00086ba [&lt;00000000c293d1ea&gt;] do_one_initcall+0xdb/0x480 [&lt;00000000aa189e6d&gt;] do_init_module+0x1cf/0x680 [&lt;00000000d513222b&gt;] load_module+0x6a50/0x70a0 [&lt;000000001fd4d529&gt;] __do_sys_finit_module+0x12f/0x1c0 [&lt;00000000b36c4c0f&gt;] do_syscall_64+0x3f/0x90 [&lt;00000000bbf20cf3&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd unreferenced object 0xffff8881127df000 (size 2048): comm \"modprobe\", pid 247, jiffies 4294972324 (age 78.728s) hex dump (first 32 bytes): 20 65 6d 70 74 79 5f 73 79 6e 74 68 5f 74 65 73 empty_synth_tes 74 20 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 t pid_t next_pi backtrace: [&lt;000000004254801a&gt;] kmalloc_trace+0x26/0x100 [&lt;00000000d4db9a3d&gt;] 0xffffffffa0008071 [&lt;00000000c31354a5&gt;] 0xffffffffa00086ce [&lt;00000000c293d1ea&gt;] do_one_initcall+0xdb/0x480 [&lt;00000000aa189e6d&gt;] do_init_module+0x1cf/0x680 [&lt;00000000d513222b&gt;] load_module+0x6a50/0x70a0 [&lt;000000001fd4d529&gt;] __do_sys_finit_module+0x12f/0x1c0 [&lt;00000000b36c4c0f&gt;] do_syscall_64+0x3f/0x90 [&lt;00000000bbf20cf3&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49801.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49801",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:03.407",
"lastModified": "2025-05-01T15:16:03.407",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix memory leak in tracing_read_pipe()\n\nkmemleak reports this issue:\n\nunreferenced object 0xffff888105a18900 (size 128):\n comm \"test_progs\", pid 18933, jiffies 4336275356 (age 22801.766s)\n hex dump (first 32 bytes):\n 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X.\n 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<00000000560143a1>] __kmalloc_node_track_caller+0x4a/0x140\n [<000000006af00822>] krealloc+0x8d/0xf0\n [<00000000c309be6a>] trace_iter_expand_format+0x99/0x150\n [<000000005a53bdb6>] trace_check_vprintf+0x1e0/0x11d0\n [<0000000065629d9d>] trace_event_printf+0xb6/0xf0\n [<000000009a690dc7>] trace_raw_output_bpf_trace_printk+0x89/0xc0\n [<00000000d22db172>] print_trace_line+0x73c/0x1480\n [<00000000cdba76ba>] tracing_read_pipe+0x45c/0x9f0\n [<0000000015b58459>] vfs_read+0x17b/0x7c0\n [<000000004aeee8ed>] ksys_read+0xed/0x1c0\n [<0000000063d3d898>] do_syscall_64+0x3b/0x90\n [<00000000a06dda7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\niter->fmt alloced in\n tracing_read_pipe() -> .. ->trace_iter_expand_format(), but not\nfreed, to fix, add free in tracing_release_pipe()"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: Fix memory leakage in tracing_read_pipe() kmemleak informa de este problema: unreferenced object 0xffff888105a18900 (size 128): comm \"test_progs\", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&amp;...BX 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [&lt;00000000560143a1&gt;] __kmalloc_nodo_rastreador_llamador+0x4a/0x140 [&lt;000000006af00822&gt;] krealloc+0x8d/0xf0 [&lt;00000000c309be6a&gt;] trace_iter_expand_format+0x99/0x150 [&lt;000000005a53bdb6&gt;] trace_check_vprintf+0x1e0/0x11d0 [&lt;0000000065629d9d&gt;] trace_event_printf+0xb6/0xf0 [&lt;000000009a690dc7&gt;] trace_raw_output_bpf_trace_printk+0x89/0xc0 [&lt;00000000d22db172&gt;] imprimir_l\u00ednea_de_seguimiento+0x73c/0x1480 [&lt;00000000cdba76ba&gt;] conducto_de_lectura_de_seguimiento+0x45c/0x9f0 [&lt;0000000015b58459&gt;] lectura_vfs+0x17b/0x7c0 [&lt;000000004aeee8ed&gt;] lectura_ksys+0xed/0x1c0 [&lt;0000000063d3d898&gt;] hacer_llamada_al_sistema_64+0x3b/0x90 [&lt;00000000a06dda7f&gt;] entrada_SYSCALL_64_despu\u00e9s_de_hwframe+0x63/0xcd iter-&gt;fmt asignado en conducto_de_lectura_de_seguimiento() -&gt; .. -&gt;trace_iter_expand_format(), pero no se libera, para solucionarlo, agregue free en tracing_release_pipe()"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49802.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49802",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:03.510",
"lastModified": "2025-05-01T15:16:03.510",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix null pointer dereference in ftrace_add_mod()\n\nThe @ftrace_mod is allocated by kzalloc(), so both the members {prev,next}\nof @ftrace_mode->list are NULL, it's not a valid state to call list_del().\nIf kstrdup() for @ftrace_mod->{func|module} fails, it goes to @out_free\ntag and calls free_ftrace_mod() to destroy @ftrace_mod, then list_del()\nwill write prev->next and next->prev, where null pointer dereference\nhappens.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCall Trace:\n <TASK>\n ftrace_mod_callback+0x20d/0x220\n ? do_filp_open+0xd9/0x140\n ftrace_process_regex.isra.51+0xbf/0x130\n ftrace_regex_write.isra.52.part.53+0x6e/0x90\n vfs_write+0xee/0x3a0\n ? __audit_filter_op+0xb1/0x100\n ? auditd_test_task+0x38/0x50\n ksys_write+0xa5/0xe0\n do_syscall_64+0x3a/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nKernel panic - not syncing: Fatal exception\n\nSo call INIT_LIST_HEAD() to initialize the list member to fix this issue."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Corregir la desreferencia de puntero nulo en ftrace_add_mod() @ftrace_mod se asigna mediante kzalloc(), por lo que ambos miembros {prev,next} de @ftrace_mode-&gt;list son NULL, no es un estado v\u00e1lido para llamar a list_del(). Si kstrdup() para @ftrace_mod-&gt;{func|module} falla, va a la etiqueta @out_free y llama a free_ftrace_mod() para destruir @ftrace_mod, entonces list_del() escribir\u00e1 prev-&gt;next y next-&gt;prev, donde ocurre la desreferencia de puntero nulo. ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 0000000000000008 Oops: 0002 [#1] PREEMPT SMP NOPTI Call Trace: ftrace_mod_callback+0x20d/0x220 ? P\u00e1nico del kernel: no se sincroniza: Excepci\u00f3n fatal Por lo tanto, llame a INIT_LIST_HEAD() para inicializar el miembro de la lista para corregir este problema."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49803.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49803",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:03.617",
"lastModified": "2025-05-01T15:16:03.617",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetdevsim: Fix memory leak of nsim_dev->fa_cookie\n\nkmemleak reports this issue:\n\nunreferenced object 0xffff8881bac872d0 (size 8):\n comm \"sh\", pid 58603, jiffies 4481524462 (age 68.065s)\n hex dump (first 8 bytes):\n 04 00 00 00 de ad be ef ........\n backtrace:\n [<00000000c80b8577>] __kmalloc+0x49/0x150\n [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim]\n [<0000000093d78e77>] full_proxy_write+0xf3/0x180\n [<000000005a662c16>] vfs_write+0x1c5/0xaf0\n [<000000007aabf84a>] ksys_write+0xed/0x1c0\n [<000000005f1d2e47>] do_syscall_64+0x3b/0x90\n [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe issue occurs in the following scenarios:\n\nnsim_dev_trap_fa_cookie_write()\n kmalloc() fa_cookie\n nsim_dev->fa_cookie = fa_cookie\n..\nnsim_drv_remove()\n\nThe fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To\nfix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdevsim: Se corrige la p\u00e9rdida de memoria de nsim_dev-&gt;fa_cookie. kmemleak informa de este problema: objeto sin referencia 0xffff8881bac872d0 (tama\u00f1o 8): comm \"sh\", pid 58603, jiffies 4481524462 (edad 68,065 s) volcado hexadecimal (primeros 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [&lt;00000000c80b8577&gt;] __kmalloc+0x49/0x150 [&lt;000000005292b8c6&gt;] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [&lt;0000000093d78e77&gt;] escritura de proxy completo+0xf3/0x180 [&lt;000000005a662c16&gt;] escritura de vfs+0x1c5/0xaf0 [&lt;000000007aabf84a&gt;] escritura de ksys+0xed/0x1c0 [&lt;000000005f1d2e47&gt;] llamada al sistema_64+0x3b/0x90 [&lt;000000006001c6ec&gt;] entrada_SYSCALL_64_after_hwframe+0x63/0xcd El problema ocurre en los siguientes escenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev-&gt;fa_cookie = fa_cookie .. nsim_drv_remove(): La fa_cookie bloqueada en nsim_dev_trap_fa_cookie_write() no se libera. Para solucionarlo, a\u00f1ada kfree(nsim_dev-&gt;fa_cookie) a nsim_drv_remove()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49804.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49804",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:03.717",
"lastModified": "2025-05-01T15:16:03.717",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390: avoid using global register for current_stack_pointer\n\nCommit 30de14b1884b (\"s390: current_stack_pointer shouldn't be a\nfunction\") made current_stack_pointer a global register variable like\non many other architectures. Unfortunately on s390 it uncovers old\ngcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87\n(\"S/390: Fix PR89775. Stackpointer save/restore instructions removed\")]\nand backported to gcc-8.4 and later. Due to this bug gcc versions prior\nto 8.4 generate broken code which leads to stack corruptions.\n\nCurrent minimal gcc version required to build the kernel is declared\nas 5.1. It is not possible to fix all old gcc versions, so work\naround this problem by avoiding using global register variable for\ncurrent_stack_pointer."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390: evitar el uso de un registro global para current_stack_pointer. El commit 30de14b1884b (\"s390: current_stack_pointer no deber\u00eda ser una funci\u00f3n\") convirti\u00f3 current_stack_pointer en una variable de registro global, como en muchas otras arquitecturas. Desafortunadamente, en s390, se descubre un antiguo error de gcc corregido solo desde gcc-9.1 [commit 3ad7fed1cc87 de gcc (\"S/390: Correcci\u00f3n de PR89775. Se eliminaron las instrucciones de guardado/restauraci\u00f3n de Stackpointer\")] y se ha retroportado a gcc-8.4 y posteriores. Debido a este error, las versiones de gcc anteriores a la 8.4 generan c\u00f3digo defectuoso que provoca corrupciones en la pila. La versi\u00f3n m\u00ednima actual de gcc requerida para compilar el kernel es la 5.1. No es posible corregir todas las versiones antiguas de gcc, por lo que se puede solucionar este problema evitando el uso de la variable de registro global para current_stack_pointer."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49805.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49805",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:03.817",
"lastModified": "2025-05-01T15:16:03.817",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: lan966x: Fix potential null-ptr-deref in lan966x_stats_init()\n\nlan966x_stats_init() calls create_singlethread_workqueue() and not\nchecked the ret value, which may return NULL. And a null-ptr-deref may\nhappen:\n\nlan966x_stats_init()\n create_singlethread_workqueue() # failed, lan966x->stats_queue is NULL\n queue_delayed_work()\n queue_delayed_work_on()\n __queue_delayed_work() # warning here, but continue\n __queue_work() # access wq->flags, null-ptr-deref\n\nCheck the ret value and return -ENOMEM if it is NULL."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: lan966x: Se corrige un posible error de referencia nulo (PTR) en lan966x_stats_init(). Lan966x_stats_init() llama a create_singlethread_workqueue() y no verifica el valor ret, lo que puede devolver NULL. Podr\u00eda ocurrir un error de referencia nulo (PTR): lan966x_stats_init() create_singlethread_workqueue() # Fall\u00f3, lan966x-&gt;stats_queue es NULL. queue_delayed_work() queue_delayed_work_on(). __queue_delayed_work() # Advertencia, pero contin\u00fae. __queue_work() # Acceso a wq-&gt;flags, PTR-deref nulo. Verifique el valor ret y devuelva -ENOMEM si es NULL."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49806.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49806",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:03.920",
"lastModified": "2025-05-01T15:16:03.920",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start()\n\nsparx_stats_init() calls create_singlethread_workqueue() and not\nchecked the ret value, which may return NULL. And a null-ptr-deref may\nhappen:\n\nsparx_stats_init()\n create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL\n queue_delayed_work()\n queue_delayed_work_on()\n __queue_delayed_work() # warning here, but continue\n __queue_work() # access wq->flags, null-ptr-deref\n\nCheck the ret value and return -ENOMEM if it is NULL. So as\nsparx5_start()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: microchip: sparx5: Se corrige un posible null-ptr-deref en sparx_stats_init() y sparx5_start(). sparx_stats_init() llama a create_singlethread_workqueue() y no comprueba el valor ret, lo que puede devolver NULL. Y puede ocurrir un null-ptr-deref: sparx_stats_init() create_singlethread_workqueue() # fall\u00f3, sparx5-&gt;stats_queue es NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # advertencia aqu\u00ed, pero contin\u00fae __queue_work() # acceso a wq-&gt;flags, null-ptr-deref Compruebe el valor ret y devuelva -ENOMEM si es NULL. As\u00ed como sparx5_start()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49807.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49807",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:04.030",
"lastModified": "2025-05-01T15:16:04.030",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix a memory leak in nvmet_auth_set_key\n\nWhen changing dhchap secrets we need to release the old\nsecrets as well.\n\nkmemleak complaint:\n--\nunreferenced object 0xffff8c7f44ed8180 (size 64):\n comm \"check\", pid 7304, jiffies 4295686133 (age 72034.246s)\n hex dump (first 32 bytes):\n 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq\n 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8\n backtrace:\n [<00000000b6fc5071>] kstrdup+0x2e/0x60\n [<00000000f0f4633f>] 0xffffffffc0e07ee6\n [<0000000053006c05>] 0xffffffffc0dff783\n [<00000000419ae922>] configfs_write_iter+0xb1/0x120\n [<000000008183c424>] vfs_write+0x2be/0x3c0\n [<000000009005a2a5>] ksys_write+0x5f/0xe0\n [<00000000cd495c89>] do_syscall_64+0x38/0x90\n [<00000000f2a84ac5>] entry_SYSCALL_64_after_hwframe+0x63/0xcd"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: corrige una p\u00e9rdida de memoria en nvmet_auth_set_key Al cambiar los secretos de dhchap, tambi\u00e9n debemos liberar los secretos antiguos. Queja de kmemleak: -- objeto sin referencia 0xffff8c7f44ed8180 (tama\u00f1o 64): comm \"check\", pid 7304, jiffies 4295686133 (edad 72034.246s) volcado hexadecimal (primeros 32 bytes): 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8 backtrace: [&lt;00000000b6fc5071&gt;] kstrdup+0x2e/0x60 [&lt;00000000f0f4633f&gt;] 0xffffffffc0e07ee6 [&lt;0000000053006c05&gt;] 0xffffffffc0dff783 [&lt;00000000419ae922&gt;] configfs_write_iter+0xb1/0x120 [&lt;000000008183c424&gt;] vfs_write+0x2be/0x3c0 [&lt;000000009005a2a5&gt;] ksys_write+0x5f/0xe0 [&lt;00000000cd495c89&gt;] do_syscall_64+0x38/0x90 [&lt;00000000f2a84ac5&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49808.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49808",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:04.130",
"lastModified": "2025-05-01T15:16:04.130",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: don't leak tagger-owned storage on switch driver unbind\n\nIn the initial commit dc452a471dba (\"net: dsa: introduce tagger-owned\nstorage for private and shared data\"), we had a call to\ntag_ops->disconnect(dst) issued from dsa_tree_free(), which is called at\ntree teardown time.\n\nThere were problems with connecting to a switch tree as a whole, so this\ngot reworked to connecting to individual switches within the tree. In\nthis process, tag_ops->disconnect(ds) was made to be called only from\nswitch.c (cross-chip notifiers emitted as a result of dynamic tag proto\nchanges), but the normal driver teardown code path wasn't replaced with\nanything.\n\nSolve this problem by adding a function that does the opposite of\ndsa_switch_setup_tag_protocol(), which is called from the equivalent\nspot in dsa_switch_teardown(). The positioning here also ensures that we\nwon't have any use-after-free in tagging protocol (*rcv) ops, since the\nteardown sequence is as follows:\n\ndsa_tree_teardown\n-> dsa_tree_teardown_master\n -> dsa_master_teardown\n -> unsets master->dsa_ptr, making no further packets match the\n ETH_P_XDSA packet type handler\n-> dsa_tree_teardown_ports\n -> dsa_port_teardown\n -> dsa_slave_destroy\n -> unregisters DSA net devices, there is even a synchronize_net()\n in unregister_netdevice_many()\n-> dsa_tree_teardown_switches\n -> dsa_switch_teardown\n -> dsa_switch_teardown_tag_protocol\n -> finally frees the tagger-owned storage"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: no filtrar almacenamiento propiedad del etiquetador al desvincular el controlador del conmutador. En la confirmaci\u00f3n inicial dc452a471dba (\"net: dsa: introducir almacenamiento propiedad del etiquetador para datos privados y compartidos\"), ten\u00edamos una llamada a tag_ops-&gt;disconnect(dst) emitida desde dsa_tree_free(), que se llama en el momento del desmontaje del \u00e1rbol. Hab\u00eda problemas con la conexi\u00f3n a un \u00e1rbol de conmutadores como un todo, por lo que esto se modific\u00f3 para conectarse a conmutadores individuales dentro del \u00e1rbol. En este proceso, tag_ops-&gt;disconnect(ds) se hizo para que se llamara solo desde switch.c (notificadores entre chips emitidos como resultado de cambios din\u00e1micos de protocolo de etiqueta), pero la ruta de c\u00f3digo normal para el desmontaje del controlador no se reemplaz\u00f3 con nada. Resuelva este problema a\u00f1adiendo una funci\u00f3n que haga lo contrario de dsa_switch_setup_tag_protocol(), que se llama desde el punto equivalente en dsa_switch_teardown(). El posicionamiento aqu\u00ed tambi\u00e9n asegura que no tendremos ning\u00fan use-after-free en las operaciones del protocolo de etiquetado (*rcv), ya que la secuencia de desmontaje es la siguiente: dsa_tree_teardown -&gt; dsa_tree_teardown_master -&gt; dsa_master_teardown -&gt; anula el ajuste master-&gt;dsa_ptr, lo que hace que no haya m\u00e1s paquetes que coincidan con el controlador de tipo de paquete ETH_P_XDSA -&gt; dsa_tree_teardown_ports -&gt; dsa_port_teardown -&gt; dsa_slave_destroy -&gt; anula el registro de los dispositivos de red DSA, incluso hay un synchronize_net() en unregister_netdevice_many() -&gt; dsa_tree_teardown_switches -&gt; dsa_switch_teardown -&gt; dsa_switch_teardown_tag_protocol -&gt; finalmente libera el almacenamiento propiedad del etiquetador"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49809.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49809",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:04.237",
"lastModified": "2025-05-01T15:16:04.237",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/x25: Fix skb leak in x25_lapb_receive_frame()\n\nx25_lapb_receive_frame() using skb_copy() to get a private copy of\nskb, the new skb should be freed in the undersized/fragmented skb\nerror handling path. Otherwise there is a memory leak."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/x25: Se corrige la fuga de skb en x25_lapb_receive_frame(). x25_lapb_receive_frame() usa skb_copy() para obtener una copia privada de skb. El nuevo skb debe liberarse en la ruta de gesti\u00f3n de errores de skb de tama\u00f1o insuficiente/fragmentado. De lo contrario, se produce una fuga de memoria."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49810.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49810",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:04.347",
"lastModified": "2025-05-01T15:16:04.347",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix missing xas_retry() calls in xarray iteration\n\nnetfslib has a number of places in which it performs iteration of an xarray\nwhilst being under the RCU read lock. It *should* call xas_retry() as the\nfirst thing inside of the loop and do \"continue\" if it returns true in case\nthe xarray walker passed out a special value indicating that the walk needs\nto be redone from the root[*].\n\nFix this by adding the missing retry checks.\n\n[*] I wonder if this should be done inside xas_find(), xas_next_node() and\n suchlike, but I'm told that's not an simple change to effect.\n\nThis can cause an oops like that below. Note the faulting address - this\nis an internal value (|0x2) returned from xarray.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000402\n...\nRIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs]\n...\nCall Trace:\n netfs_rreq_assess+0xa6/0x240 [netfs]\n netfs_readpage+0x173/0x3b0 [netfs]\n ? init_wait_var_entry+0x50/0x50\n filemap_read_page+0x33/0xf0\n filemap_get_pages+0x2f2/0x3f0\n filemap_read+0xaa/0x320\n ? do_filp_open+0xb2/0x150\n ? rmqueue+0x3be/0xe10\n ceph_read_iter+0x1fe/0x680 [ceph]\n ? new_sync_read+0x115/0x1a0\n new_sync_read+0x115/0x1a0\n vfs_read+0xf3/0x180\n ksys_read+0x5f/0xe0\n do_syscall_64+0x38/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nChanges:\n========\nver #2)\n - Changed an unsigned int to a size_t to reduce the likelihood of an\n overflow as per Willy's suggestion.\n - Added an additional patch to fix the maths."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Se corrigen las llamadas xas_retry() faltantes en la iteraci\u00f3n de un xarray. netfslib realiza la iteraci\u00f3n de un xarray en varios lugares bajo el bloqueo de lectura de la RCU. *Deber\u00eda* llamar a xas_retry() como primer paso dentro del bucle y ejecutar \"continue\" si devuelve verdadero en caso de que el rastreador de xarrays haya pasado un valor especial que indique que el recorrido debe rehacerse desde la ra\u00edz. [*] Se puede solucionar a\u00f1adiendo las comprobaciones de reintento faltantes. [*] Me pregunto si esto deber\u00eda hacerse dentro de xas_find(), xas_next_node() y similares, pero me han dicho que no es un cambio sencillo de implementar. Esto puede causar un error como el que se muestra a continuaci\u00f3n. Observe la direcci\u00f3n del error: se trata de un valor interno (|0x2) devuelto por xarray. ERROR: desreferencia de puntero NULL del n\u00facleo, direcci\u00f3n: 0000000000000402 ... RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs] ... Seguimiento de llamadas: netfs_rreq_assess+0xa6/0x240 [netfs] netfs_readpage+0x173/0x3b0 [netfs] ? init_wait_var_entry+0x50/0x50 filemap_read_page+0x33/0xf0 filemap_get_pages+0x2f2/0x3f0 filemap_read+0xaa/0x320 ? do_filp_open+0xb2/0x150 ? rmqueue+0x3be/0xe10 ceph_read_iter+0x1fe/0x680 [ceph] ? new_sync_read+0x115/0x1a0 new_sync_read+0x115/0x1a0 vfs_read+0xf3/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Changes: ======== ver #2) - Se cambi\u00f3 un int sin signo a un size_t para reducir la probabilidad de un desbordamiento seg\u00fan la sugerencia de Willy. - Se agreg\u00f3 un parche adicional para corregir las matem\u00e1ticas."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49811.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49811",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:04.450",
"lastModified": "2025-05-01T15:16:04.450",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrbd: use after free in drbd_create_device()\n\nThe drbd_destroy_connection() frees the \"connection\" so use the _safe()\niterator to prevent a use after free."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drbd: use-after-free en drbd_create_device(). drbd_destroy_connection() libera la \"conexi\u00f3n\", as\u00ed que use el iterador _safe() para evitar un use-after-free."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49812.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49812",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:04.560",
"lastModified": "2025-05-01T15:16:04.560",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbridge: switchdev: Fix memory leaks when changing VLAN protocol\n\nThe bridge driver can offload VLANs to the underlying hardware either\nvia switchdev or the 8021q driver. When the former is used, the VLAN is\nmarked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV'\nprivate flag.\n\nTo avoid the memory leaks mentioned in the cited commit, the bridge\ndriver will try to delete a VLAN via the 8021q driver if the VLAN is not\nmarked with the previously mentioned flag.\n\nWhen the VLAN protocol of the bridge changes, switchdev drivers are\nnotified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but\nthe 8021q driver is also called to add the existing VLANs with the new\nprotocol and delete them with the old protocol.\n\nIn case the VLANs were offloaded via switchdev, the above behavior is\nboth redundant and buggy. Redundant because the VLANs are already\nprogrammed in hardware and drivers that support VLAN protocol change\n(currently only mlx5) change the protocol upon the switchdev attribute\nnotification. Buggy because the 8021q driver is called despite these\nVLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to\nmemory leaks [1] when the VLANs are deleted.\n\nFix by not calling the 8021q driver for VLANs that were already\nprogrammed via switchdev.\n\n[1]\nunreferenced object 0xffff8881f6771200 (size 256):\n comm \"ip\", pid 446855, jiffies 4298238841 (age 55.240s)\n hex dump (first 32 bytes):\n 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<00000000012819ac>] vlan_vid_add+0x437/0x750\n [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920\n [<000000000632b56f>] br_changelink+0x3d6/0x13f0\n [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0\n [<00000000f6276baf>] rtnl_newlink+0x5f/0x90\n [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00\n [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340\n [<0000000010588814>] netlink_unicast+0x438/0x710\n [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40\n [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0\n [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0\n [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0\n [<00000000684f7e25>] __sys_sendmsg+0xab/0x130\n [<000000004538b104>] do_syscall_64+0x3d/0x90\n [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bridge: switchdev: Fix memory leakage when Changing VLAN protocol El controlador del puente puede descargar VLAN al hardware subyacente mediante switchdev o el controlador 8021q. Cuando se utiliza el primero, la VLAN se marca en el controlador del puente con el indicador privado 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. Para evitar las fugas de memoria mencionadas en la confirmaci\u00f3n citada, el controlador del puente intentar\u00e1 eliminar una VLAN mediante el controlador 8021q si la VLAN no est\u00e1 marcada con el indicador mencionado anteriormente. Cuando cambia el protocolo VLAN del puente, se notifica a los controladores switchdev mediante el atributo 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL', pero tambi\u00e9n se llama al controlador 8021q para agregar las VLAN existentes con el nuevo protocolo y eliminarlas con el protocolo anterior. En caso de que las VLAN se descargaran mediante switchdev, el comportamiento anterior es redundante y presenta errores. Redundante porque las VLAN ya est\u00e1n programadas en el hardware y los controladores compatibles con el cambio de protocolo de VLAN (actualmente solo mlx5) cambian el protocolo al recibir la notificaci\u00f3n del atributo switchdev. Presenta errores porque se llama al controlador 8021q a pesar de que estas VLAN est\u00e1n marcadas con 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. Esto provoca fugas de memoria [1] al eliminar las VLAN. Se soluciona no llamando al controlador 8021q para las VLAN ya programadas mediante switchdev. [1] objeto sin referencia 0xffff8881f6771200 (tama\u00f1o 256): comm \"ip\", pid 446855, jiffies 4298238841 (edad 55.240s) volcado hexadecimal (primeros 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [&lt;00000000012819ac&gt;] vlan_vid_add+0x437/0x750 [&lt;00000000f2281fad&gt;] __br_vlan_set_proto+0x289/0x920 [&lt;000000000632b56f&gt;] br_changelink+0x3d6/0x13f0 [&lt;0000000089d25f04&gt;] __rtnl_newlink+0x8ae/0x14c0 [&lt;00000000f6276baf&gt;] rtnl_newlink+0x5f/0x90 [&lt;00000000746dc902&gt;] rtnetlink_rcv_msg+0x336/0xa00 [&lt;000000001c2241c0&gt;] netlink_rcv_skb+0x11d/0x340 [&lt;0000000010588814&gt;] netlink_unicast+0x438/0x710 [&lt;00000000e1a4cd5c&gt;] netlink_sendmsg+0x788/0xc40 [&lt;00000000e8992d4e&gt;] sock_sendmsg+0xb0/0xe0 [&lt;00000000621b8f91&gt;] ____sys_sendmsg+0x4ff/0x6d0 [&lt;000000000ea26996&gt;] ___sys_sendmsg+0x12e/0x1b0 [&lt;00000000684f7e25&gt;] __sys_sendmsg+0xab/0x130 [&lt;000000004538b104&gt;] do_syscall_64+0x3d/0x90 [&lt;0000000091ed9678&gt;] entry_SYSCALL_64_after_hwframe+0x46/0xb0 "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49813.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49813",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:04.673",
"lastModified": "2025-05-01T15:16:04.673",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ena: Fix error handling in ena_init()\n\nThe ena_init() won't destroy workqueue created by\ncreate_singlethread_workqueue() when pci_register_driver() failed.\nCall destroy_workqueue() when pci_register_driver() failed to prevent the\nresource leak."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ena: Se corrige el manejo de errores en ena_init(). Ena_init() no destruye la cola de trabajo creada por create_singlethread_workqueue() cuando pci_register_driver() falla. Se llama a destroy_workqueue() cuando pci_register_driver() falla para evitar la fuga de recursos."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49814.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49814",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:04.787",
"lastModified": "2025-05-01T15:16:04.787",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nkcm: close race conditions on sk_receive_queue\n\nsk->sk_receive_queue is protected by skb queue lock, but for KCM\nsockets its RX path takes mux->rx_lock to protect more than just\nskb queue. However, kcm_recvmsg() still only grabs the skb queue\nlock, so race conditions still exist.\n\nWe can teach kcm_recvmsg() to grab mux->rx_lock too but this would\nintroduce a potential performance regression as struct kcm_mux can\nbe shared by multiple KCM sockets.\n\nSo we have to enforce skb queue lock in requeue_rx_msgs() and handle\nskb peek case carefully in kcm_wait_data(). Fortunately,\nskb_recv_datagram() already handles it nicely and is widely used by\nother sockets, we can just switch to skb_recv_datagram() after\ngetting rid of the unnecessary sock lock in kcm_recvmsg() and\nkcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,\nso it is safe to get rid of this check too.\n\nI ran the original syzbot reproducer for 30 min without seeing any\nissue."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kcm: condiciones de ejecuci\u00f3n cerradas en sk_receive_queue. sk-&gt;sk_receive_queue est\u00e1 protegido por el bloqueo de cola skb, pero para los sockets KCM su ruta RX toma mux-&gt;rx_lock para proteger m\u00e1s que solo la cola skb. Sin embargo, kcm_recvmsg() todav\u00eda solo captura el bloqueo de cola skb, por lo que las condiciones de ejecuci\u00f3n a\u00fan existen. Podemos ense\u00f1ar a kcm_recvmsg() a capturar tambi\u00e9n mux-&gt;rx_lock, pero esto introducir\u00eda una posible regresi\u00f3n del rendimiento, ya que la estructura kcm_mux puede ser compartida por varios sockets KCM. Por lo tanto, debemos aplicar el bloqueo de cola skb en requeue_rx_msgs() y manejar el caso de skb peek con cuidado en kcm_wait_data(). Afortunadamente, skb_recv_datagram() ya lo gestiona correctamente y es ampliamente utilizado por otros sockets. Podemos cambiar a skb_recv_datagram() tras eliminar el bloqueo de sock innecesario en kcm_recvmsg() y kcm_splice_read(). Nota: Los sockets KCM no utilizan SOCK_DONE, por lo que tambi\u00e9n es seguro omitir esta comprobaci\u00f3n. Ejecut\u00e9 el reproductor syzbot original durante 30 minutos sin observar ning\u00fan problema."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49815.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49815",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:04.893",
"lastModified": "2025-05-01T15:16:04.893",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix missing xas_retry() in fscache mode\n\nThe xarray iteration only holds the RCU read lock and thus may encounter\nXA_RETRY_ENTRY if there's process modifying the xarray concurrently.\nThis will cause oops when referring to the invalid entry.\n\nFix this by adding the missing xas_retry(), which will make the\niteration wind back to the root node if XA_RETRY_ENTRY is encountered."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: se corrige la falta de xas_retry() en el modo fscache. La iteraci\u00f3n del array x solo mantiene el bloqueo de lectura de la RCU y, por lo tanto, puede encontrar XA_RETRY_ENTRY si hay un proceso que modifica el array x simult\u00e1neamente. Esto causar\u00e1 errores al hacer referencia a la entrada no v\u00e1lida. Se soluciona a\u00f1adiendo la falta de xas_retry(), lo que har\u00e1 que la iteraci\u00f3n regrese al nodo ra\u00edz si se encuentra XA_RETRY_ENTRY."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49817.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49817",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:05.103",
"lastModified": "2025-05-01T15:16:05.103",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mhi: Fix memory leak in mhi_net_dellink()\n\nMHI driver registers network device without setting the\nneeds_free_netdev flag, and does NOT call free_netdev() when\nunregisters network device, which causes a memory leak.\n\nThis patch calls free_netdev() to fix it since netdev_priv\nis used after unregister."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mhi: Se corrige la p\u00e9rdida de memoria en mhi_net_dellink(). El controlador MHI registra el dispositivo de red sin configurar el indicador needs_free_netdev y NO llama a free_netdev() al cancelar el registro del dispositivo de red, lo que provoca una p\u00e9rdida de memoria. Este parche llama a free_netdev() para corregirla, ya que netdev_priv se utiliza despu\u00e9s de cancelar el registro."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49818.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49818",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:05.207",
"lastModified": "2025-05-01T15:16:05.207",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: fix misuse of put_device() in mISDN_register_device()\n\nWe should not release reference by put_device() before calling device_initialize()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mISDN: corregir el uso incorrecto de put_device() en mISDN_register_device() No debemos liberar la referencia de put_device() antes de llamar a device_initialize()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49819.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49819",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:05.317",
"lastModified": "2025-05-01T15:16:05.317",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nocteon_ep: fix potential memory leak in octep_device_setup()\n\nWhen occur unsupported_dev and mbox init errors, it did not free oct->conf\nand iounmap() oct->mmio[i].hw_addr. That would trigger memory leak problem.\nAdd kfree() for oct->conf and iounmap() for oct->mmio[i].hw_addr under\nunsupported_dev and mbox init errors to fix the problem."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeon_ep: se corrige una posible fuga de memoria en octep_device_setup(). Cuando se producen errores unsupported_dev e init de mbox, no se liberan oct-&gt;conf ni iounmap() de oct-&gt;mmio[i].hw_addr. Esto causar\u00eda un problema de fuga de memoria. Se a\u00f1aden kfree() para oct-&gt;conf e iounmap() para oct-&gt;mmio[i].hw_addr en los errores unsupported_dev e init de mbox para solucionar el problema."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49820.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49820",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:05.413",
"lastModified": "2025-05-01T15:16:05.413",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmctp i2c: don't count unused / invalid keys for flow release\n\nWe're currently hitting the WARN_ON in mctp_i2c_flow_release:\n\n if (midev->release_count > midev->i2c_lock_count) {\n WARN_ONCE(1, \"release count overflow\");\n\nThis may be hit if we expire a flow before sending the first packet it\ncontains - as we will not be pairing the increment of release_count\n(performed on flow release) with the i2c lock operation (only\nperformed on actual TX).\n\nTo fix this, only release a flow if we've encountered it previously (ie,\ndev_flow_state does not indicate NEW), as we will mark the flow as\nACTIVE at the same time as accounting for the i2c lock operation. We\nalso need to add an INVALID flow state, to indicate when we've done the\nrelease."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mctp i2c: no cuente las claves no utilizadas o no v\u00e1lidas para la liberaci\u00f3n del flujo Actualmente estamos alcanzando el WARN_ON en mctp_i2c_flow_release: if (midev-&gt;release_count &gt; midev-&gt;i2c_lock_count) { WARN_ONCE(1, \"release count overflow\"); Esto puede ser alcanzado si expiramos un flujo antes de enviar el primer paquete que contiene, ya que no estaremos emparejando el incremento de release_count (realizado en la liberaci\u00f3n del flujo) con la operaci\u00f3n de bloqueo i2c (solo se realiza en TX real). Para corregir esto, solo libere un flujo si lo hemos encontrado previamente (es decir, dev_flow_state no indica NUEVO), ya que marcaremos el flujo como ACTIVO al mismo tiempo que contabilizamos la operaci\u00f3n de bloqueo i2c. Tambi\u00e9n necesitamos agregar un estado de flujo INV\u00c1LIDO, para indicar cu\u00e1ndo hemos realizado la liberaci\u00f3n."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49821.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49821",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:05.513",
"lastModified": "2025-05-01T15:16:05.513",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: fix possible memory leak in mISDN_dsp_element_register()\n\nAfer commit 1fa5ae857bb1 (\"driver core: get rid of struct device's\nbus_id string array\"), the name of device is allocated dynamically,\nuse put_device() to give up the reference, so that the name can be\nfreed in kobject_cleanup() when the refcount is 0.\n\nThe 'entry' is going to be freed in mISDN_dsp_dev_release(), so the\nkfree() is removed. list_del() is called in mISDN_dsp_dev_release(),\nso it need be initialized."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mISDN: corrige posible p\u00e9rdida de memoria en mISDN_dsp_element_register() Despu\u00e9s de la confirmaci\u00f3n 1fa5ae857bb1 (\"n\u00facleo del controlador: deshacerse de la matriz de cadenas bus_id del dispositivo struct\"), el nombre del dispositivo se asigna din\u00e1micamente, use put_device() para renunciar a la referencia, de modo que el nombre se pueda liberar en kobject_cleanup() cuando refcount sea 0. La 'entrada' se liberar\u00e1 en mISDN_dsp_dev_release(), por lo que se elimina kfree(). list_del() se llama en mISDN_dsp_dev_release(), por lo que necesita inicializarse."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49822.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49822",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:05.623",
"lastModified": "2025-05-01T15:16:05.623",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix connections leak when tlink setup failed\n\nIf the tlink setup failed, lost to put the connections, then\nthe module refcnt leak since the cifsd kthread not exit.\n\nAlso leak the fscache info, and for next mount with fsc, it will\nprint the follow errors:\n CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST)\n\nLet's check the result of tlink setup, and do some cleanup."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige la fuga de conexiones al fallar la configuraci\u00f3n de Tlink. Si la configuraci\u00f3n de Tlink falla, se pierden las conexiones y se produce una fuga de referencia del m\u00f3dulo, ya que el kthread de cifsd no finaliza. Tambi\u00e9n se filtra la informaci\u00f3n de fscache, y en el siguiente montaje con fsc, se mostrar\u00e1n los siguientes errores: CIFS: La clave del volumen de cach\u00e9 ya est\u00e1 en uso (cifs,127.0.0.1:445,TEST). Revisemos el resultado de la configuraci\u00f3n de Tlink y realicemos una limpieza."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49823.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49823",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:05.723",
"lastModified": "2025-05-01T15:16:05.723",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix error handling in ata_tdev_add()\n\nIn ata_tdev_add(), the return value of transport_add_device() is\nnot checked. As a result, it causes null-ptr-deref while removing\nthe module, because transport_remove_device() is called to remove\nthe device that was not added.\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000000d0\nCPU: 13 PID: 13603 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #36\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x48/0x3a0\nlr : device_del+0x44/0x3a0\nCall trace:\n device_del+0x48/0x3a0\n attribute_container_class_device_del+0x28/0x40\n transport_remove_classdev+0x60/0x7c\n attribute_container_device_trigger+0x118/0x120\n transport_remove_device+0x20/0x30\n ata_tdev_delete+0x24/0x50 [libata]\n ata_tlink_delete+0x40/0xa0 [libata]\n ata_tport_delete+0x2c/0x60 [libata]\n ata_port_detach+0x148/0x1b0 [libata]\n ata_pci_remove_one+0x50/0x80 [libata]\n ahci_remove_one+0x4c/0x8c [ahci]\n\nFix this by checking and handling return value of transport_add_device()\nin ata_tdev_add(). In the error path, device_del() is called to delete\nthe device which was added earlier in this function, and ata_tdev_free()\nis called to free ata_dev."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-transport: correcci\u00f3n del manejo de errores en ata_tdev_add(). En ata_tdev_add(), no se comprueba el valor de retorno de transport_add_device(). Como resultado, se genera una referencia nula al eliminar el m\u00f3dulo, ya que se llama a transport_remove_device() para eliminar el dispositivo no a\u00f1adido. No se puede manejar la desreferencia del puntero NULL del n\u00facleo en la direcci\u00f3n virtual 00000000000000d0 CPU: 13 PID: 13603 Comm: rmmod Kdump: cargado Tainted: GW 6.1.0-rc3+ #36 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x3a0 lr : device_del+0x44/0x3a0 Rastreo de llamadas: device_del+0x48/0x3a0 attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tdev_delete+0x24/0x50 [libata] ata_tlink_delete+0x40/0xa0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Para solucionar este problema, verifique y gestione el valor de retorno de transport_add_device() en ata_tdev_add(). En la ruta de error, se llama a device_del() para eliminar el dispositivo a\u00f1adido previamente en esta funci\u00f3n, y ata_tdev_free() para liberar ata_dev."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49824.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49824",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:05.830",
"lastModified": "2025-05-01T15:16:05.830",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix error handling in ata_tlink_add()\n\nIn ata_tlink_add(), the return value of transport_add_device() is\nnot checked. As a result, it causes null-ptr-deref while removing\nthe module, because transport_remove_device() is called to remove\nthe device that was not added.\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000000d0\nCPU: 33 PID: 13850 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #12\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x48/0x39c\nlr : device_del+0x44/0x39c\nCall trace:\n device_del+0x48/0x39c\n attribute_container_class_device_del+0x28/0x40\n transport_remove_classdev+0x60/0x7c\n attribute_container_device_trigger+0x118/0x120\n transport_remove_device+0x20/0x30\n ata_tlink_delete+0x88/0xb0 [libata]\n ata_tport_delete+0x2c/0x60 [libata]\n ata_port_detach+0x148/0x1b0 [libata]\n ata_pci_remove_one+0x50/0x80 [libata]\n ahci_remove_one+0x4c/0x8c [ahci]\n\nFix this by checking and handling return value of transport_add_device()\nin ata_tlink_add()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-transport: correcci\u00f3n del manejo de errores en ata_tlink_add(). En ata_tlink_add(), no se comprueba el valor de retorno de transport_add_device(). Como resultado, se genera una referencia nula al eliminar el m\u00f3dulo, ya que se llama a transport_remove_device() para eliminar el dispositivo no a\u00f1adido. No se puede manejar la desreferencia del puntero NULL del n\u00facleo en la direcci\u00f3n virtual 00000000000000d0 CPU: 33 PID: 13850 Comm: rmmod Kdump: cargado Tainted: GW 6.1.0-rc3+ #12 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Rastreo de llamadas: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tlink_delete+0x88/0xb0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Solucione esto verificando y manejando el valor de retorno de transport_add_device() en ata_tlink_add()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49825.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49825",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:05.937",
"lastModified": "2025-05-01T15:16:05.937",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix error handling in ata_tport_add()\n\nIn ata_tport_add(), the return value of transport_add_device() is\nnot checked. As a result, it causes null-ptr-deref while removing\nthe module, because transport_remove_device() is called to remove\nthe device that was not added.\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000000d0\nCPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #8\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x48/0x39c\nlr : device_del+0x44/0x39c\nCall trace:\n device_del+0x48/0x39c\n attribute_container_class_device_del+0x28/0x40\n transport_remove_classdev+0x60/0x7c\n attribute_container_device_trigger+0x118/0x120\n transport_remove_device+0x20/0x30\n ata_tport_delete+0x34/0x60 [libata]\n ata_port_detach+0x148/0x1b0 [libata]\n ata_pci_remove_one+0x50/0x80 [libata]\n ahci_remove_one+0x4c/0x8c [ahci]\n\nFix this by checking and handling return value of transport_add_device()\nin ata_tport_add()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-transport: correcci\u00f3n del manejo de errores en ata_tport_add(). En ata_tport_add(), no se comprueba el valor de retorno de transport_add_device(). Como resultado, se genera una referencia nula al eliminar el m\u00f3dulo, ya que se llama a transport_remove_device() para eliminar el dispositivo no a\u00f1adido. No se puede manejar la desreferencia del puntero NULL del n\u00facleo en la direcci\u00f3n virtual 00000000000000d0 CPU: 12 PID: 13605 Comm: rmmod Kdump: cargado Tainted: GW 6.1.0-rc3+ #8 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Rastreo de llamadas: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tport_delete+0x34/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Solucione esto verificando y manejando el valor de retorno de transport_add_device() en ata_tport_add()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49826.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49826",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:06.043",
"lastModified": "2025-05-01T15:16:06.043",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix double ata_host_put() in ata_tport_add()\n\nIn the error path in ata_tport_add(), when calling put_device(),\nata_tport_release() is called, it will put the refcount of 'ap->host'.\n\nAnd then ata_host_put() is called again, the refcount is decreased\nto 0, ata_host_release() is called, all ports are freed and set to\nnull.\n\nWhen unbinding the device after failure, ata_host_stop() is called\nto release the resources, it leads a null-ptr-deref(), because all\nthe ports all freed and null.\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000008\nCPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8\npstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : ata_host_stop+0x3c/0x84 [libata]\nlr : release_nodes+0x64/0xd0\nCall trace:\n ata_host_stop+0x3c/0x84 [libata]\n release_nodes+0x64/0xd0\n devres_release_all+0xbc/0x1b0\n device_unbind_cleanup+0x20/0x70\n really_probe+0x158/0x320\n __driver_probe_device+0x84/0x120\n driver_probe_device+0x44/0x120\n __driver_attach+0xb4/0x220\n bus_for_each_dev+0x78/0xdc\n driver_attach+0x2c/0x40\n bus_add_driver+0x184/0x240\n driver_register+0x80/0x13c\n __pci_register_driver+0x4c/0x60\n ahci_pci_driver_init+0x30/0x1000 [ahci]\n\nFix this by removing redundant ata_host_put() in the error path."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-transport: correcci\u00f3n de un error doble de ata_host_put() en ata_tport_add(). En la ruta de error de ata_tport_add(), al llamar a put_device(), se llama a ata_tport_release(), lo que resta el recuento de referencias de 'ap-&gt;host'. A continuaci\u00f3n, se vuelve a llamar a ata_host_put(), el recuento de referencias se reduce a 0 y se llama a ata_host_release(), liberando todos los puertos y estableci\u00e9ndolos en nulo. Al desvincular el dispositivo tras un fallo, se llama a ata_host_stop() para liberar los recursos, lo que genera un error null-ptr-deref(), ya que todos los puertos est\u00e1n liberados y en nulo. No se puede manejar la desreferencia del puntero NULL del n\u00facleo en la direcci\u00f3n virtual 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: cargado Contaminado: GE 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Rastreo de llamadas: ata_host_stop+0x3c/0x84 [libata] release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70 really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci] Solucione esto eliminando ata_host_put() redundante en la ruta de error."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49827.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49827",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:06.150",
"lastModified": "2025-05-01T15:16:06.150",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: Fix potential null-ptr-deref in drm_vblank_destroy_worker()\n\ndrm_vblank_init() call drmm_add_action_or_reset() with\ndrm_vblank_init_release() as action. If __drmm_add_action() failed, will\ndirectly call drm_vblank_init_release() with the vblank whose worker is\nNULL. As the resule, a null-ptr-deref will happen in\nkthread_destroy_worker(). Add the NULL check before calling\ndrm_vblank_destroy_worker().\n\nBUG: null-ptr-deref\nKASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]\nCPU: 5 PID: 961 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf-dirty\nRIP: 0010:kthread_destroy_worker+0x25/0xb0\n Call Trace:\n <TASK>\n drm_vblank_init_release+0x124/0x220 [drm]\n ? drm_crtc_vblank_restore+0x8b0/0x8b0 [drm]\n __drmm_add_action_or_reset+0x41/0x50 [drm]\n drm_vblank_init+0x282/0x310 [drm]\n vkms_init+0x35f/0x1000 [vkms]\n ? 0xffffffffc4508000\n ? lock_is_held_type+0xd7/0x130\n ? __kmem_cache_alloc_node+0x1c2/0x2b0\n ? lock_is_held_type+0xd7/0x130\n ? 0xffffffffc4508000\n do_one_initcall+0xd0/0x4f0\n ...\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: Se corrige la posible desreferencia PTR nula en la llamada drm_vblank_destroy_worker(). drm_vblank_init() llama a drmm_add_action_or_reset() con la acci\u00f3n drm_vblank_init_release(). Si __drmm_add_action() falla, se llamar\u00e1 directamente a drm_vblank_init_release() con el vblank cuyo trabajador sea NULL. Como resultado, se producir\u00e1 una desreferencia PTR nula en kthread_destroy_worker(). Se a\u00f1ade la comprobaci\u00f3n de valores NULL antes de llamar a drm_vblank_destroy_worker(). ERROR: null-ptr-deref KASAN: null-ptr-deref en el rango [0x0000000000000068-0x000000000000006f] CPU: 5 PID: 961 Comm: modprobe No contaminado 6.0.0-11331-gd465bff130bf-dirty RIP: 0010:kthread_destroy_worker+0x25/0xb0 Seguimiento de llamadas: drm_vblank_init_release+0x124/0x220 [drm] ? drm_crtc_vblank_restore+0x8b0/0x8b0 [drm] __drmm_add_action_or_reset+0x41/0x50 [drm] drm_vblank_init+0x282/0x310 [drm] vkms_init+0x35f/0x1000 [vkms] ? 0xffffffffc4508000 ? lock_is_held_type+0xd7/0x130 ? __kmem_cache_alloc_node+0x1c2/0x2b0 ? lock_is_held_type+0xd7/0x130 ? 0xffffffffc4508000 do_one_initcall+0xd0/0x4f0 ... do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49828.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49828",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:06.260",
"lastModified": "2025-05-01T15:16:06.260",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhugetlbfs: don't delete error page from pagecache\n\nThis change is very similar to the change that was made for shmem [1], and\nit solves the same problem but for HugeTLBFS instead.\n\nCurrently, when poison is found in a HugeTLB page, the page is removed\nfrom the page cache. That means that attempting to map or read that\nhugepage in the future will result in a new hugepage being allocated\ninstead of notifying the user that the page was poisoned. As [1] states,\nthis is effectively memory corruption.\n\nThe fix is to leave the page in the page cache. If the user attempts to\nuse a poisoned HugeTLB page with a syscall, the syscall will fail with\nEIO, the same error code that shmem uses. For attempts to map the page,\nthe thread will get a BUS_MCEERR_AR SIGBUS.\n\n[1]: commit a76054266661 (\"mm: shmem: don't truncate page if memory failure happens\")"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hugetlbfs: no elimine la p\u00e1gina de error de la cach\u00e9 de p\u00e1ginas Este cambio es muy similar al cambio que se realiz\u00f3 para shmem [1] y resuelve el mismo problema, pero para HugeTLBFS. Actualmente, cuando se encuentra veneno en una p\u00e1gina HugeTLB, la p\u00e1gina se elimina de la cach\u00e9 de p\u00e1ginas. Eso significa que intentar mapear o leer esa p\u00e1gina enorme en el futuro dar\u00e1 como resultado que se asigne una nueva p\u00e1gina enorme en lugar de notificar al usuario que la p\u00e1gina fue envenenada. Como indica [1], esto es efectivamente corrupci\u00f3n de memoria. La soluci\u00f3n es dejar la p\u00e1gina en la cach\u00e9 de p\u00e1ginas. Si el usuario intenta usar una p\u00e1gina HugeTLB envenenada con una llamada al sistema, la llamada al sistema fallar\u00e1 con EIO, el mismo c\u00f3digo de error que usa shmem. Para los intentos de mapear la p\u00e1gina, el hilo obtendr\u00e1 un SIGBUS BUS_MCEERR_AR. [1]: commit a76054266661 (\"mm: shmem: no truncar la p\u00e1gina si se produce un fallo de memoria\")"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49829.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49829",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:06.373",
"lastModified": "2025-05-01T15:16:06.373",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/scheduler: fix fence ref counting\n\nWe leaked dependency fences when processes were beeing killed.\n\nAdditional to that grab a reference to the last scheduled fence."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/scheduler: correcci\u00f3n del conteo de referencias de vallas. Se filtraron vallas de dependencias al finalizar procesos. Adem\u00e1s, se obtuvo una referencia a la \u00faltima valla programada."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49830.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49830",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:06.470",
"lastModified": "2025-05-01T15:16:06.470",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drv: Fix potential memory leak in drm_dev_init()\n\ndrm_dev_init() will add drm_dev_init_release() as a callback. When\ndrmm_add_action() failed, the release function won't be added. As the\nresult, the ref cnt added by device_get() in drm_dev_init() won't be put\nby drm_dev_init_release(), which leads to the memleak. Use\ndrmm_add_action_or_reset() instead of drmm_add_action() to prevent\nmemleak.\n\nunreferenced object 0xffff88810bc0c800 (size 2048):\n comm \"modprobe\", pid 8322, jiffies 4305809845 (age 15.292s)\n hex dump (first 32 bytes):\n e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................\n 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<.............\n backtrace:\n [<000000007251f72d>] __kmalloc+0x4b/0x1c0\n [<0000000045f21f26>] platform_device_alloc+0x2d/0xe0\n [<000000004452a479>] platform_device_register_full+0x24/0x1c0\n [<0000000089f4ea61>] 0xffffffffa0736051\n [<00000000235b2441>] do_one_initcall+0x7a/0x380\n [<0000000001a4a177>] do_init_module+0x5c/0x230\n [<000000002bf8a8e2>] load_module+0x227d/0x2420\n [<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140\n [<00000000c99fc324>] do_syscall_64+0x3f/0x90\n [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/drv: Se solucion\u00f3 una posible fuga de memoria en drm_dev_init(). drm_dev_init() a\u00f1adir\u00e1 drm_dev_init_release() como devoluci\u00f3n de llamada. Si drmm_add_action() falla, la funci\u00f3n de liberaci\u00f3n no se a\u00f1adir\u00e1. Como resultado, el valor de referencia a\u00f1adido por device_get() en drm_dev_init() no se incluir\u00e1 en drm_dev_init_release(), lo que provoca la fuga de memoria. Utilice drmm_add_action_or_reset() en lugar de drmm_add_action() para evitar la fuga de memoria. objeto sin referencia 0xffff88810bc0c800 (tama\u00f1o 2048): comm \"modprobe\", pid 8322, jiffies 4305809845 (antig\u00fcedad 15.292s) volcado hexadecimal (primeros 32 bytes): e8 cc c0 0b 81 88 ff ff ff ff ff ff ff 00 00 00 00 ................ 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $&lt;............. backtrace: [&lt;000000007251f72d&gt;] __kmalloc+0x4b/0x1c0 [&lt;0000000045f21f26&gt;] platform_device_alloc+0x2d/0xe0 [&lt;000000004452a479&gt;] platform_device_register_full+0x24/0x1c0 [&lt;0000000089f4ea61&gt;] 0xffffffffa0736051 [&lt;00000000235b2441&gt;] do_one_initcall+0x7a/0x380 [&lt;0000000001a4a177&gt;] do_init_module+0x5c/0x230 [&lt;000000002bf8a8e2&gt;] load_module+0x227d/0x2420 [&lt;00000000637d6d0a&gt;] __do_sys_finit_module+0xd5/0x140 [&lt;00000000c99fc324&gt;] do_syscall_64+0x3f/0x90 [&lt;000000004d85aa77&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49831.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49831",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:06.573",
"lastModified": "2025-05-01T15:16:06.573",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: initialize device's zone info for seeding\n\nWhen performing seeding on a zoned filesystem it is necessary to\ninitialize each zoned device's btrfs_zoned_device_info structure,\notherwise mounting the filesystem will cause a NULL pointer dereference.\n\nThis was uncovered by fstests' testcase btrfs/163."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: inicializar la informaci\u00f3n de zona del dispositivo para la propagaci\u00f3n. Al propagar en un sistema de archivos con zonas, es necesario inicializar la estructura btrfs_zoned_device_info de cada dispositivo; de lo contrario, al montar el sistema de archivos se producir\u00e1 una desreferencia de puntero nulo. Esto fue descubierto por el caso de prueba btrfs/163 de fstests."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49832.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49832",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:06.673",
"lastModified": "2025-05-01T15:16:06.673",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map\n\nHere is the BUG report by KASAN about null pointer dereference:\n\nBUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50\nRead of size 1 at addr 0000000000000000 by task python3/2640\nCall Trace:\n strcmp\n __of_find_property\n of_find_property\n pinctrl_dt_to_map\n\nkasprintf() would return NULL pointer when kmalloc() fail to allocate.\nSo directly return ENOMEM, if kasprintf() return NULL pointer."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: devicetree: correcci\u00f3n de la desreferencia de puntero nulo en pinctrl_dt_to_map Aqu\u00ed est\u00e1 el informe de ERROR de KASAN sobre la desreferencia de puntero nulo: ERROR: KASAN: null-ptr-deref en strcmp+0x2e/0x50 Lectura de tama\u00f1o 1 en la direcci\u00f3n 0000000000000000 por la tarea python3/2640 Rastreo de llamadas: strcmp __of_find_property of_find_property pinctrl_dt_to_map kasprintf() devolver\u00eda un puntero NULL cuando kmalloc() no pudiera asignar. Por lo tanto, devuelve directamente ENOMEM, si kasprintf() devuelve un puntero NULL."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49833.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49833",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:06.780",
"lastModified": "2025-05-01T15:16:06.780",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: clone zoned device info when cloning a device\n\nWhen cloning a btrfs_device, we're not cloning the associated\nbtrfs_zoned_device_info structure of the device in case of a zoned\nfilesystem.\n\nLater on this leads to a NULL pointer dereference when accessing the\ndevice's zone_info for instance when setting a zone as active.\n\nThis was uncovered by fstests' testcase btrfs/161."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: clonar informaci\u00f3n de dispositivo zonificado al clonar un dispositivo. Al clonar un btrfs_device, no se clona la estructura btrfs_zoned_device_info asociada al dispositivo en el caso de un sistema de archivos zonificado. Posteriormente, esto provoca una desreferencia de puntero nulo al acceder a zone_info del dispositivo, por ejemplo, al activar una zona. Esto fue descubierto por el caso de prueba btrfs/161 de fstests."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49834.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49834",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:06.873",
"lastModified": "2025-05-01T15:16:06.873",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix use-after-free bug of ns_writer on remount\n\nIf a nilfs2 filesystem is downgraded to read-only due to metadata\ncorruption on disk and is remounted read/write, or if emergency read-only\nremount is performed, detaching a log writer and synchronizing the\nfilesystem can be done at the same time.\n\nIn these cases, use-after-free of the log writer (hereinafter\nnilfs->ns_writer) can happen as shown in the scenario below:\n\n Task1 Task2\n -------------------------------- ------------------------------\n nilfs_construct_segment\n nilfs_segctor_sync\n init_wait\n init_waitqueue_entry\n add_wait_queue\n schedule\n nilfs_remount (R/W remount case)\n\t\t\t\t nilfs_attach_log_writer\n nilfs_detach_log_writer\n nilfs_segctor_destroy\n kfree\n finish_wait\n _raw_spin_lock_irqsave\n __raw_spin_lock_irqsave\n do_raw_spin_lock\n debug_spin_lock_before <-- use-after-free\n\nWhile Task1 is sleeping, nilfs->ns_writer is freed by Task2. After Task1\nwaked up, Task1 accesses nilfs->ns_writer which is already freed. This\nscenario diagram is based on the Shigeru Yoshida's post [1].\n\nThis patch fixes the issue by not detaching nilfs->ns_writer on remount so\nthat this UAF race doesn't happen. Along with this change, this patch\nalso inserts a few necessary read-only checks with superblock instance\nwhere only the ns_writer pointer was used to check if the filesystem is\nread-only."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige el error de use-after-free de ns_writer al volver a montar Si un sistema de archivos nilfs2 se degrada a solo lectura debido a la corrupci\u00f3n de metadatos en el disco y se vuelve a montar en modo de lectura/escritura, o si se realiza un remontaje de solo lectura de emergencia, se puede desconectar un escritor de registros y sincronizar el sistema de archivos al mismo tiempo. En estos casos, el use-after-free del escritor de registros (en adelante nilfs-&gt;ns_writer) puede ocurrir como se muestra en el siguiente escenario: Tarea1 Tarea2 -------------------------------- ---------------------------------- nilfs_construct_segment nilfs_segctor_sync init_wait init_waitqueue_entry add_wait_queue schedule nilfs_remount (caso de remontaje de R/W) nilfs_attach_log_writer nilfs_detach_log_writer nilfs_segctor_destroy kfree finish_wait _raw_spin_lock_irqsave __raw_spin_lock_irqsave do_raw_spin_lock debug_spin_lock_before &lt;-- use-after-free Mientras la Tarea1 est\u00e1 en reposo, nilfs-&gt;ns_writer es liberado por la Tarea2. Despu\u00e9s de que la Tarea1 se despierta, la Tarea1 accede a nilfs-&gt;ns_writer que ya est\u00e1 liberado. Este diagrama de escenario se basa en la publicaci\u00f3n de Shigeru Yoshida [1]. Este parche corrige el problema al no desvincular nilfs-&gt;ns_writer al volver a montar, lo que evita que se produzca esta ejecuci\u00f3n UAF. Adem\u00e1s de este cambio, este parche tambi\u00e9n inserta algunas comprobaciones de solo lectura necesarias con la instancia de superbloque, donde solo se usaba el puntero ns_writer para comprobar si el sistema de archivos era de solo lectura."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49835.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49835",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:06.980",
"lastModified": "2025-05-01T15:16:06.980",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: fix potential memleak in 'add_widget_node'\n\nAs 'kobject_add' may allocated memory for 'kobject->name' when return error.\nAnd in this function, if call 'kobject_add' failed didn't free kobject.\nSo call 'kobject_put' to recycling resources."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: se corrige una posible fuga de memoria en 'add_widget_node'. 'kobject_add' podr\u00eda asignar memoria a 'kobject-&gt;name' cuando devuelve un error. En esta funci\u00f3n, si la llamada a 'kobject_add' falla, no se libera kobject. Por lo tanto, se llama a 'kobject_put' para reciclar recursos."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49836.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49836",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:07.087",
"lastModified": "2025-05-01T15:16:07.087",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsiox: fix possible memory leak in siox_device_add()\n\nIf device_register() returns error in siox_device_add(),\nthe name allocated by dev_set_name() need be freed. As\ncomment of device_register() says, it should use put_device()\nto give up the reference in the error path. So fix this\nby calling put_device(), then the name can be freed in\nkobject_cleanup(), and sdevice is freed in siox_device_release(),\nset it to null in error path."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: siox: Se corrige una posible fuga de memoria en siox_device_add(). Si device_register() devuelve un error en siox_device_add(), se debe liberar el nombre asignado por dev_set_name(). Como se indica en el comentario de device_register(), se debe usar put_device() para liberar la referencia en la ruta de error. Para solucionar esto, se debe llamar a put_device(); de esta manera, se puede liberar el nombre en kobject_cleanup() y sdevice se libera en siox_device_release(); config\u00farelo como nulo en la ruta de error."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49837.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49837",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:07.187",
"lastModified": "2025-05-01T15:16:07.187",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix memory leaks in __check_func_call\n\nkmemleak reports this issue:\n\nunreferenced object 0xffff88817139d000 (size 2048):\n comm \"test_progs\", pid 33246, jiffies 4307381979 (age 45851.820s)\n hex dump (first 32 bytes):\n 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<0000000045f075f0>] kmalloc_trace+0x27/0xa0\n [<0000000098b7c90a>] __check_func_call+0x316/0x1230\n [<00000000b4c3c403>] check_helper_call+0x172e/0x4700\n [<00000000aa3875b7>] do_check+0x21d8/0x45e0\n [<000000001147357b>] do_check_common+0x767/0xaf0\n [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0\n [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940\n [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650\n [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0\n [<00000000946ee250>] do_syscall_64+0x3b/0x90\n [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe root case here is: In function prepare_func_exit(), the callee is\nnot released in the abnormal scenario after \"state->curframe--;\". To\nfix, move \"state->curframe--;\" to the very bottom of the function,\nright when we free callee and reset frame[] pointer to NULL, as Andrii\nsuggested.\n\nIn addition, function __check_func_call() has a similar problem. In\nthe abnormal scenario before \"state->curframe++;\", the callee also\nshould be released by free_func_state()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrigen fugas de memoria en __check_func_call kmemleak informa de este problema: objeto sin referencia 0xffff88817139d000 (tama\u00f1o 2048): comm \"test_progs\", pid 33246, jiffies 4307381979 (edad 45851.820s) volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [&lt;0000000045f075f0&gt;] kmalloc_trace+0x27/0xa0 [&lt;0000000098b7c90a&gt;] __check_func_call+0x316/0x1230 [&lt;00000000b4c3c403&gt;] check_helper_call+0x172e/0x4700 [&lt;00000000aa3875b7&gt;] do_check+0x21d8/0x45e0 [&lt;000000001147357b&gt;] do_check_common+0x767/0xaf0 [&lt;00000000b5a595b4&gt;] bpf_check+0x43e3/0x5bc0 [&lt;0000000011e391b1&gt;] bpf_prog_load+0xf26/0x1940 [&lt;0000000007f765c0&gt;] __sys_bpf+0xd2c/0x3650 [&lt;00000000839815d6&gt;] __x64_sys_bpf+0x75/0xc0 [&lt;00000000946ee250&gt;] do_syscall_64+0x3b/0x90 [&lt;0000000000506b7f&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd El caso ra\u00edz aqu\u00ed es: En la funci\u00f3n prepare_func_exit(), el llamado no se libera en el escenario anormal despu\u00e9s de \"state-&gt;curframe--;\". Para solucionarlo, mueva \"state-&gt;curframe--;\" al final de la funci\u00f3n, justo cuando liberamos al destinatario y restablecemos el puntero frame[] a NULL, como sugiri\u00f3 Andrii. Adem\u00e1s, la funci\u00f3n __check_func_call() presenta un problema similar. En el escenario anormal anterior a \"state-&gt;curframe++;\", el destinatario tambi\u00e9n deber\u00eda ser liberado por free_func_state()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49838.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49838",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:07.290",
"lastModified": "2025-05-01T15:16:07.290",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: clear out_curr if all frag chunks of current msg are pruned\n\nA crash was reported by Zhen Chen:\n\n list_del corruption, ffffa035ddf01c18->next is NULL\n WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0\n RIP: 0010:__list_del_entry_valid+0x59/0xe0\n Call Trace:\n sctp_sched_dequeue_common+0x17/0x70 [sctp]\n sctp_sched_fcfs_dequeue+0x37/0x50 [sctp]\n sctp_outq_flush_data+0x85/0x360 [sctp]\n sctp_outq_uncork+0x77/0xa0 [sctp]\n sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp]\n sctp_side_effects+0x37/0xe0 [sctp]\n sctp_do_sm+0xd0/0x230 [sctp]\n sctp_primitive_SEND+0x2f/0x40 [sctp]\n sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp]\n sctp_sendmsg+0x3d5/0x440 [sctp]\n sock_sendmsg+0x5b/0x70\n\nand in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream\nout_curr outq while this outq was empty.\n\nNormally stream->out_curr must be set to NULL once all frag chunks of\ncurrent msg are dequeued, as we can see in sctp_sched_dequeue_done().\nHowever, in sctp_prsctp_prune_unsent() as it is not a proper dequeue,\nsctp_sched_dequeue_done() is not called to do this.\n\nThis patch is to fix it by simply setting out_curr to NULL when the\nlast frag chunk of current msg is dequeued from out_curr stream in\nsctp_prsctp_prune_unsent()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: borrar out_curr si se eliminan todos los fragmentos del mensaje actual. Zhen Chen inform\u00f3 de un fallo: corrupci\u00f3n de list_del, ffffa035ddf01c18-&gt;next es NULL ADVERTENCIA: CPU: 1 PID: 250682 en lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Rastreo de llamadas: sctp_sched_dequeue_common+0x17/0x70 [sctp] sctp_sched_fcfs_dequeue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp] sctp_side_effects+0x37/0xe0 [sctp] sctp_do_sm+0xd0/0x230 [sctp] sctp_primitive_SEND+0x2f/0x40 [sctp] sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp] sctp_sendmsg+0x3d5/0x440 [sctp] sock_sendmsg+0x5b/0x70 y en sctp_sched_fcfs_dequeue() quit\u00f3 de la cola un fragmento del flujo out_curr outq mientras este outq estaba vac\u00edo. Normalmente, stream-&gt;out_curr debe establecerse en NULL una vez que se hayan desencolado todos los fragmentos del mensaje actual, como se puede ver en sctp_sched_dequeue_done(). Sin embargo, en sctp_prsctp_prune_unsent(), dado que no es una desencola adecuada, no se llama a sctp_sched_dequeue_done() para realizar esto. Este parche soluciona este problema simplemente estableciendo out_curr en NULL cuando se desencola el \u00faltimo fragmento del mensaje actual del flujo out_curr en sctp_prsctp_prune_unsent()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49839.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49839",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:07.390",
"lastModified": "2025-05-01T15:16:07.390",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_transport_sas: Fix error handling in sas_phy_add()\n\nIf transport_add_device() fails in sas_phy_add(), the kernel will crash\ntrying to delete the device in transport_remove_device() called from\nsas_remove_host().\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000108\nCPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173\npstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x54/0x3d0\nlr : device_del+0x37c/0x3d0\nCall trace:\n device_del+0x54/0x3d0\n attribute_container_class_device_del+0x28/0x38\n transport_remove_classdev+0x6c/0x80\n attribute_container_device_trigger+0x108/0x110\n transport_remove_device+0x28/0x38\n sas_phy_delete+0x30/0x60 [scsi_transport_sas]\n do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas]\n device_for_each_child+0x68/0xb0\n sas_remove_children+0x40/0x50 [scsi_transport_sas]\n sas_remove_host+0x20/0x38 [scsi_transport_sas]\n hisi_sas_remove+0x40/0x68 [hisi_sas_main]\n hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw]\n platform_remove+0x2c/0x60\n\nFix this by checking and handling return value of transport_add_device()\nin sas_phy_add()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_transport_sas: Corregir error de manejo en sas_phy_add() Si transport_add_device() falla en sas_phy_add(), el kernel se bloquear\u00e1 al intentar eliminar el dispositivo en transport_remove_device() llamado desde sas_remove_host(). No se puede manejar la desreferencia del puntero NULL del n\u00facleo en la direcci\u00f3n virtual 0000000000000108 CPU: 61 PID: 42829 Comm: rmmod Kdump: cargado Tainted: GW 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Rastreo de llamadas: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_phy_delete+0x30/0x60 [scsi_transport_sas] do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x40/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] hisi_sas_remove+0x40/0x68 [hisi_sas_main] hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw] platform_remove+0x2c/0x60 Fix this by checking and handling return value of transport_add_device() in sas_phy_add(). "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49840.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49840",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:07.493",
"lastModified": "2025-05-01T15:16:07.493",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()\n\nWe got a syzkaller problem because of aarch64 alignment fault\nif KFENCE enabled. When the size from user bpf program is an odd\nnumber, like 399, 407, etc, it will cause the struct skb_shared_info's\nunaligned access. As seen below:\n\n BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032\n\n Use-after-free read at 0xffff6254fffac077 (in kfence-#213):\n __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline]\n arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]\n arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline]\n atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline]\n __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032\n skb_clone+0xf4/0x214 net/core/skbuff.c:1481\n ____bpf_clone_redirect net/core/filter.c:2433 [inline]\n bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420\n bpf_prog_d3839dd9068ceb51+0x80/0x330\n bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]\n bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53\n bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594\n bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]\n __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]\n __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381\n\n kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512\n\n allocated by task 15074 on cpu 0 at 1342.585390s:\n kmalloc include/linux/slab.h:568 [inline]\n kzalloc include/linux/slab.h:675 [inline]\n bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191\n bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512\n bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]\n __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]\n __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381\n __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381\n\nTo fix the problem, we adjust @size so that (@size + @hearoom) is a\nmultiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info\nis aligned to a cache line."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, test_run: Se solucion\u00f3 un problema de alineaci\u00f3n en bpf_prog_test_run_skb(). Se detect\u00f3 un problema en syzkaller debido a un fallo de alineaci\u00f3n de aarch64 si KFENCE estaba habilitado. Cuando el tama\u00f1o del programa bpf del usuario es un n\u00famero impar, como 399, 407, etc., se produce un acceso no alineado a la estructura skb_shared_info. Como se ve a continuaci\u00f3n: ERROR: KFENCE: lectura de use-after-free en __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Lectura de use-after-free en 0xffff6254fffac077 (en kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [en l\u00ednea] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [en l\u00ednea] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [en l\u00ednea] atomic_inc include/asm-generic/atomic-instrumented.h:241 [en l\u00ednea] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [en l\u00ednea] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [en l\u00ednea] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [en l\u00ednea] __do_sys_bpf kernel/bpf/syscall.c:4441 [en l\u00ednea] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, tama\u00f1o=407, cach\u00e9=kmalloc-512 asignado por la tarea 15074 en la CPU 0 a las 1342.585390 s: kmalloc include/linux/slab.h:568 [en l\u00ednea] kzalloc include/linux/slab.h:675 [en l\u00ednea] bpf_test_init.isra.0+0xac/0x290 Para corregir el problema, ajustamos @size de modo que (@size + @hearoom) sea un m\u00faltiplo de SMP_CACHE_BYTES. As\u00ed nos aseguramos de que la estructura skb_shared_info est\u00e9 alineada con una l\u00ednea de cach\u00e9."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49841.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49841",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:07.600",
"lastModified": "2025-05-01T15:16:07.600",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: imx: Add missing .thaw_noirq hook\n\nThe following warning is seen with non-console UART instance when\nsystem hibernates.\n\n[ 37.371969] ------------[ cut here ]------------\n[ 37.376599] uart3_root_clk already disabled\n[ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0\n...\n[ 37.506986] Call trace:\n[ 37.509432] clk_core_disable+0xa4/0xb0\n[ 37.513270] clk_disable+0x34/0x50\n[ 37.516672] imx_uart_thaw+0x38/0x5c\n[ 37.520250] platform_pm_thaw+0x30/0x6c\n[ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4\n[ 37.528972] device_resume+0x7c/0x160\n[ 37.532633] dpm_resume+0xe8/0x230\n[ 37.536036] hibernation_snapshot+0x288/0x430\n[ 37.540397] hibernate+0x10c/0x2e0\n[ 37.543798] state_store+0xc4/0xd0\n[ 37.547203] kobj_attr_store+0x1c/0x30\n[ 37.550953] sysfs_kf_write+0x48/0x60\n[ 37.554619] kernfs_fop_write_iter+0x118/0x1ac\n[ 37.559063] new_sync_write+0xe8/0x184\n[ 37.562812] vfs_write+0x230/0x290\n[ 37.566214] ksys_write+0x68/0xf4\n[ 37.569529] __arm64_sys_write+0x20/0x2c\n[ 37.573452] invoke_syscall.constprop.0+0x50/0xf0\n[ 37.578156] do_el0_svc+0x11c/0x150\n[ 37.581648] el0_svc+0x30/0x140\n[ 37.584792] el0t_64_sync_handler+0xe8/0xf0\n[ 37.588976] el0t_64_sync+0x1a0/0x1a4\n[ 37.592639] ---[ end trace 56e22eec54676d75 ]---\n\nOn hibernating, pm core calls into related hooks in sequence like:\n\n .freeze\n .freeze_noirq\n .thaw_noirq\n .thaw\n\nWith .thaw_noirq hook being absent, the clock will be disabled in a\nunbalanced call which results the warning above.\n\n imx_uart_freeze()\n clk_prepare_enable()\n imx_uart_suspend_noirq()\n clk_disable()\n imx_uart_thaw\n clk_disable_unprepare()\n\nAdding the missing .thaw_noirq hook as imx_uart_resume_noirq() will have\nthe call sequence corrected as below and thus fix the warning.\n\n imx_uart_freeze()\n clk_prepare_enable()\n imx_uart_suspend_noirq()\n clk_disable()\n imx_uart_resume_noirq()\n clk_enable()\n imx_uart_thaw\n clk_disable_unprepare()"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: imx: Agregar el gancho .thaw_noirq faltante. La siguiente advertencia se ve con una instancia UART que no es de consola cuando el sistema hiberna. [ 37.371969] ------------[ cortar aqu\u00ed ]------------ [ 37.376599] uart3_root_clk ya est\u00e1 deshabilitado [ 37.380810] ADVERTENCIA: CPU: 0 PID: 296 en drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 ... [ 37.506986] Rastreo de llamadas: [ 37.509432] clk_core_disable+0xa4/0xb0 [ 37.513270] clk_disable+0x34/0x50 [ 37.516672] imx_uart_thaw+0x38/0x5c [ 37.520250] platform_pm_thaw+0x30/0x6c [ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4 [ 37.528972] device_resume+0x7c/0x160 [ 37.532633] dpm_resume+0xe8/0x230 [ 37.536036] hibernation_snapshot+0x288/0x430 [ 37.540397] hibernate+0x10c/0x2e0 [ 37.543798] state_store+0xc4/0xd0 [ 37.547203] kobj_attr_store+0x1c/0x30 [ 37.550953] sysfs_kf_write+0x48/0x60 [ 37.554619] kernfs_fop_write_iter+0x118/0x1ac [ 37.559063] new_sync_write+0xe8/0x184 [ 37.562812] vfs_write+0x230/0x290 [ 37.566214] ksys_write+0x68/0xf4 [ 37.569529] __arm64_sys_write+0x20/0x2c [ 37.573452] invoke_syscall.constprop.0+0x50/0xf0 [ 37.578156] do_el0_svc+0x11c/0x150 [ 37.581648] el0_svc+0x30/0x140 [ 37.584792] el0t_64_sync_handler+0xe8/0xf0 [ 37.588976] el0t_64_sync+0x1a0/0x1a4 [ 37.592639] ---[ end trace 56e22eec54676d75 ] Al hibernar, el n\u00facleo pm llama a los ganchos relacionados en secuencia como: .freeze .freeze_noirq .thaw_noirq .thaw Si el gancho .thaw_noirq est\u00e1 ausente, el reloj se deshabilitar\u00e1 en una llamada desequilibrada que genera la advertencia anterior. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_thaw clk_disable_unprepare() Agregar el gancho .thaw_noirq faltante como imx_uart_resume_noirq() corregir\u00e1 la secuencia de llamada como se muestra a continuaci\u00f3n y, por lo tanto, solucionar\u00e1 la advertencia. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_resume_noirq() clk_enable() imx_uart_thaw clk_disable_unprepare()"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49842.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49842",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:07.703",
"lastModified": "2025-05-01T15:16:07.703",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Fix use-after-free in snd_soc_exit()\n\nKASAN reports a use-after-free:\n\nBUG: KASAN: use-after-free in device_del+0xb5b/0xc60\nRead of size 8 at addr ffff888008655050 by task rmmod/387\nCPU: 2 PID: 387 Comm: rmmod\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n<TASK>\ndump_stack_lvl+0x79/0x9a\nprint_report+0x17f/0x47b\nkasan_report+0xbb/0xf0\ndevice_del+0xb5b/0xc60\nplatform_device_del.part.0+0x24/0x200\nplatform_device_unregister+0x2e/0x40\nsnd_soc_exit+0xa/0x22 [snd_soc_core]\n__do_sys_delete_module.constprop.0+0x34f/0x5b0\ndo_syscall_64+0x3a/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n...\n</TASK>\n\nIt's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,\nbut its ret is ignored, which makes soc_dummy_dev unregistered twice.\n\nsnd_soc_init()\n snd_soc_util_init()\n platform_device_register_simple(soc_dummy_dev)\n platform_driver_register() # fail\n \tplatform_device_unregister(soc_dummy_dev)\n platform_driver_register() # success\n...\nsnd_soc_exit()\n snd_soc_util_exit()\n # soc_dummy_dev will be unregistered for second time\n\nTo fix it, handle error and stop snd_soc_init() when util_init() fail.\nAlso clean debugfs when util_init() or driver_register() fail."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: n\u00facleo: Se corrige el use-after-free en snd_soc_exit() KASAN informa un use-after-free: ERROR: KASAN: use-after-free en device_del+0xb5b/0xc60 Lectura de tama\u00f1o 8 en la direcci\u00f3n ffff888008655050 por la tarea rmmod/387 CPU: 2 PID: 387 Comm: rmmod Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) Rastreo de llamadas: dump_stack_lvl+0x79/0x9a print_report+0x17f/0x47b kasan_report+0xbb/0xf0 device_del+0xb5b/0xc60 platform_device_del.part.0+0x24/0x200 platform_device_unregister+0x2e/0x40 snd_soc_exit+0xa/0x22 [snd_soc_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail, but its ret is ignored, which makes soc_dummy_dev unregistered twice. snd_soc_init() snd_soc_util_init() platform_device_register_simple(soc_dummy_dev) platform_driver_register() # fail platform_device_unregister(soc_dummy_dev) platform_driver_register() # success ... snd_soc_exit() snd_soc_util_exit() # soc_dummy_dev will be unregistered for second time To fix it, handle error and stop snd_soc_init() when util_init() fail. Also clean debugfs when util_init() or driver_register() fail. "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49843.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49843",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:07.807",
"lastModified": "2025-05-01T15:16:07.807",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Migrate in CPU page fault use current mm\n\nmigrate_vma_setup shows below warning because we don't hold another\nprocess mm mmap_lock. We should use current vmf->vma->vm_mm instead, the\ncaller already hold current mmap lock inside CPU page fault handler.\n\n WARNING: CPU: 10 PID: 3054 at include/linux/mmap_lock.h:155 find_vma\n Call Trace:\n walk_page_range+0x76/0x150\n migrate_vma_setup+0x18a/0x640\n svm_migrate_vram_to_ram+0x245/0xa10 [amdgpu]\n svm_migrate_to_ram+0x36f/0x470 [amdgpu]\n do_swap_page+0xcfe/0xec0\n __handle_mm_fault+0x96b/0x15e0\n handle_mm_fault+0x13f/0x3e0\n do_user_addr_fault+0x1e7/0x690"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Migrar en la CPU con fallos de p\u00e1gina al usar la funci\u00f3n mm actual. El m\u00e9todo \"migrate_vma_setup\" muestra la siguiente advertencia porque no se mantiene el bloqueo mmap_lock de otro proceso. Deber\u00edamos usar la funci\u00f3n \"vmf-&gt;vma-&gt;vm_mm\" actual, ya que el llamador ya mantiene el bloqueo mmap actual dentro del controlador de fallos de p\u00e1gina de la CPU. ADVERTENCIA: CPU: 10 PID: 3054 en include/linux/mmap_lock.h:155 Seguimiento de llamadas find_vma: walk_page_range+0x76/0x150 migrate_vma_setup+0x18a/0x640 svm_migrate_vram_to_ram+0x245/0xa10 [amdgpu] svm_migrate_to_ram+0x36f/0x470 [amdgpu] do_swap_page+0xcfe/0xec0 __handle_mm_fault+0x96b/0x15e0 handle_mm_fault+0x13f/0x3e0 do_user_addr_fault+0x1e7/0x690"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49844.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49844",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:07.907",
"lastModified": "2025-05-01T15:16:07.907",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: dev: fix skb drop check\n\nIn commit a6d190f8c767 (\"can: skb: drop tx skb if in listen only\nmode\") the priv->ctrlmode element is read even on virtual CAN\ninterfaces that do not create the struct can_priv at startup. This\nout-of-bounds read may lead to CAN frame drops for virtual CAN\ninterfaces like vcan and vxcan.\n\nThis patch mainly reverts the original commit and adds a new helper\nfor CAN interface drivers that provide the required information in\nstruct can_priv.\n\n[mkl: patch pch_can, too]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: dev: fix skb drop check. En el commit a6d190f8c767 (\"can: skb: drop tx skb if in listen only mode\"), el elemento priv-&gt;ctrlmode se lee incluso en interfaces CAN virtuales que no crean la estructura can_priv al inicio. Esta lectura fuera de los l\u00edmites puede provocar la p\u00e9rdida de tramas CAN en interfaces CAN virtuales como vcan y vxcan. Este parche revierte principalmente la confirmaci\u00f3n original y a\u00f1ade un nuevo asistente para los controladores de interfaz CAN que proporciona la informaci\u00f3n necesaria en la estructura can_priv. [mkl: parchear tambi\u00e9n pch_can]"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49845.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49845",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:08.010",
"lastModified": "2025-05-01T15:16:08.010",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: j1939_send_one(): fix missing CAN header initialization\n\nThe read access to struct canxl_frame::len inside of a j1939 created\nskbuff revealed a missing initialization of reserved and later filled\nelements in struct can_frame.\n\nThis patch initializes the 8 byte CAN header with zero."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: j1939_send_one(): se corrige la falta de inicializaci\u00f3n del encabezado CAN. El acceso de lectura a struct canxl_frame::len dentro de un skbuff creado con j1939 revel\u00f3 la falta de inicializaci\u00f3n de elementos reservados y posteriormente rellenados en struct can_frame. Este parche inicializa el encabezado CAN de 8 bytes con cero."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49846.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49846",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:08.113",
"lastModified": "2025-05-01T15:16:08.113",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nudf: Fix a slab-out-of-bounds write bug in udf_find_entry()\n\nSyzbot reported a slab-out-of-bounds Write bug:\n\nloop0: detected capacity change from 0 to 2048\n==================================================================\nBUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0\nfs/udf/namei.c:253\nWrite of size 105 at addr ffff8880123ff896 by task syz-executor323/3610\n\nCPU: 0 PID: 3610 Comm: syz-executor323 Not tainted\n6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0\nHardware name: Google Compute Engine/Google Compute Engine, BIOS\nGoogle 10/11/2022\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106\n print_address_description+0x74/0x340 mm/kasan/report.c:284\n print_report+0x107/0x1f0 mm/kasan/report.c:395\n kasan_report+0xcd/0x100 mm/kasan/report.c:495\n kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189\n memcpy+0x3c/0x60 mm/kasan/shadow.c:66\n udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253\n udf_lookup+0xef/0x340 fs/udf/namei.c:309\n lookup_open fs/namei.c:3391 [inline]\n open_last_lookups fs/namei.c:3481 [inline]\n path_openat+0x10e6/0x2df0 fs/namei.c:3710\n do_filp_open+0x264/0x4f0 fs/namei.c:3740\n do_sys_openat2+0x124/0x4e0 fs/open.c:1310\n do_sys_open fs/open.c:1326 [inline]\n __do_sys_creat fs/open.c:1402 [inline]\n __se_sys_creat fs/open.c:1396 [inline]\n __x64_sys_creat+0x11f/0x160 fs/open.c:1396\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7ffab0d164d9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89\nf7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01\nf0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9\nRDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180\nRBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000\nR10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n </TASK>\n\nAllocated by task 3610:\n kasan_save_stack mm/kasan/common.c:45 [inline]\n kasan_set_track+0x3d/0x60 mm/kasan/common.c:52\n ____kasan_kmalloc mm/kasan/common.c:371 [inline]\n __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380\n kmalloc include/linux/slab.h:576 [inline]\n udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243\n udf_lookup+0xef/0x340 fs/udf/namei.c:309\n lookup_open fs/namei.c:3391 [inline]\n open_last_lookups fs/namei.c:3481 [inline]\n path_openat+0x10e6/0x2df0 fs/namei.c:3710\n do_filp_open+0x264/0x4f0 fs/namei.c:3740\n do_sys_openat2+0x124/0x4e0 fs/open.c:1310\n do_sys_open fs/open.c:1326 [inline]\n __do_sys_creat fs/open.c:1402 [inline]\n __se_sys_creat fs/open.c:1396 [inline]\n __x64_sys_creat+0x11f/0x160 fs/open.c:1396\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe buggy address belongs to the object at ffff8880123ff800\n which belongs to the cache kmalloc-256 of size 256\nThe buggy address is located 150 bytes inside of\n 256-byte region [ffff8880123ff800, ffff8880123ff900)\n\nThe buggy address belongs to the physical page:\npage:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000\nindex:0x0 pfn:0x123fe\nhead:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0\nflags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)\nraw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40\nraw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as allocated\npage last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(),\npid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0\n create_dummy_stack mm/page_owner.c:\n---truncated---"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udf: Se corrige un error de escritura fuera de los l\u00edmites en udf_find_entry() Syzbot inform\u00f3 un error de escritura fuera de los l\u00edmites: loop0: se detect\u00f3 un cambio de capacidad de 0 a 2048 ======================================================================= ERROR: KASAN: slab-out-of-bounds en udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 Escritura de tama\u00f1o 105 en la direcci\u00f3n ffff8880123ff896 por la tarea syz-executor323/3610 CPU: 0 PID: 3610 Comm: syz-executor323 No contaminado 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189 memcpy+0x3c/0x60 mm/kasan/shadow.c:66 udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7ffab0d164d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9 RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180 RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000 R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Asignado por la tarea 3610: kasan_save_stack mm/kasan/common.c:45 [en l\u00ednea] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:371 [en l\u00ednea] __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:576 [en l\u00ednea] udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [en l\u00ednea] open_last_lookups fs/namei.c:3481 [en l\u00ednea] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [en l\u00ednea] __do_sys_creat fs/open.c:1402 [en l\u00ednea] __se_sys_creat fs/open.c:1396 [en l\u00ednea] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd La direcci\u00f3n con errores pertenece al objeto en ffff8880123ff800 que pertenece a la cach\u00e9 kmalloc-256 de tama\u00f1o 256 La direcci\u00f3n con errores se encuentra 150 bytes dentro de la regi\u00f3n de 256 bytes [ffff8880123ff800, ffff8880123ff900) La direcci\u00f3n con errores pertenece a la p\u00e1gina f\u00edsica: page:ffffea000048ff80 refcount:1 mapcount:0 mapping:000000000000000 index:0x0 pfn:0x123fe cabeza:ffffea000048ff80 orden:1 compuesto_mapcount:0 compuesto_pincount:0 banderas: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) sin formato: 00fff00000010200 ffffea00004b8500 muerto000000000003 ffff888012041b40 sin formato: 000000000000000 0000000080100010 00000001ffffffff 0000000000000000 p\u00e1gina volcada porque: kasan: se detect\u00f3 un acceso incorrecto page_owner rastrea la p\u00e1gina como asignada \u00faltima p\u00e1gina asignada mediante orden 0, migrationtype Inamovible, gfp_---truncado---"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49847.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49847",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:08.223",
"lastModified": "2025-05-01T15:16:08.223",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: Fix segmentation fault at module unload\n\nMove am65_cpsw_nuss_phylink_cleanup() call to after\nam65_cpsw_nuss_cleanup_ndev() so phylink is still valid\nto prevent the below Segmentation fault on module remove when\nfirst slave link is up.\n\n[ 31.652944] Unable to handle kernel paging request at virtual address 00040008000005f4\n[ 31.684627] Mem abort info:\n[ 31.687446] ESR = 0x0000000096000004\n[ 31.704614] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 31.720663] SET = 0, FnV = 0\n[ 31.723729] EA = 0, S1PTW = 0\n[ 31.740617] FSC = 0x04: level 0 translation fault\n[ 31.756624] Data abort info:\n[ 31.759508] ISV = 0, ISS = 0x00000004\n[ 31.776705] CM = 0, WnR = 0\n[ 31.779695] [00040008000005f4] address between user and kernel address ranges\n[ 31.808644] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[ 31.814928] Modules linked in: wlcore_sdio wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10dif_ce phy_gmii_sel ti_am65_cpsw_nuss(-) sch_fq_codel ipv6\n[ 31.828776] CPU: 0 PID: 1026 Comm: modprobe Not tainted 6.1.0-rc2-00012-gfabfcf7dafdb-dirty #160\n[ 31.837547] Hardware name: Texas Instruments AM625 (DT)\n[ 31.842760] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 31.849709] pc : phy_stop+0x18/0xf8\n[ 31.853202] lr : phylink_stop+0x38/0xf8\n[ 31.857031] sp : ffff80000a0839f0\n[ 31.860335] x29: ffff80000a0839f0 x28: ffff000000de1c80 x27: 0000000000000000\n[ 31.867462] x26: 0000000000000000 x25: 0000000000000000 x24: ffff80000a083b98\n[ 31.874589] x23: 0000000000000800 x22: 0000000000000001 x21: ffff000001bfba90\n[ 31.881715] x20: ffff0000015ee000 x19: 0004000800000200 x18: 0000000000000000\n[ 31.888842] x17: ffff800076c45000 x16: ffff800008004000 x15: 000058e39660b106\n[ 31.895969] x14: 0000000000000144 x13: 0000000000000144 x12: 0000000000000000\n[ 31.903095] x11: 000000000000275f x10: 00000000000009e0 x9 : ffff80000a0837d0\n[ 31.910222] x8 : ffff000000de26c0 x7 : ffff00007fbd6540 x6 : ffff00007fbd64c0\n[ 31.917349] x5 : ffff00007fbd0b10 x4 : ffff00007fbd0b10 x3 : ffff00007fbd3920\n[ 31.924476] x2 : d0a07fcff8b8d500 x1 : 0000000000000000 x0 : 0004000800000200\n[ 31.931603] Call trace:\n[ 31.934042] phy_stop+0x18/0xf8\n[ 31.937177] phylink_stop+0x38/0xf8\n[ 31.940657] am65_cpsw_nuss_ndo_slave_stop+0x28/0x1e0 [ti_am65_cpsw_nuss]\n[ 31.947452] __dev_close_many+0xa4/0x140\n[ 31.951371] dev_close_many+0x84/0x128\n[ 31.955115] unregister_netdevice_many+0x130/0x6d0\n[ 31.959897] unregister_netdevice_queue+0x94/0xd8\n[ 31.964591] unregister_netdev+0x24/0x38\n[ 31.968504] am65_cpsw_nuss_cleanup_ndev.isra.0+0x48/0x70 [ti_am65_cpsw_nuss]\n[ 31.975637] am65_cpsw_nuss_remove+0x58/0xf8 [ti_am65_cpsw_nuss]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: ti: am65-cpsw: Se corrige el error de segmentaci\u00f3n en la descarga del m\u00f3dulo. Mueve la llamada am65_cpsw_nuss_phylink_cleanup() despu\u00e9s de am65_cpsw_nuss_cleanup_ndev() para que phylink siga siendo v\u00e1lido para evitar el siguiente error de segmentaci\u00f3n en la eliminaci\u00f3n del m\u00f3dulo cuando el primer enlace esclavo est\u00e1 activo. [ 31.652944] No se puede manejar la solicitud de paginaci\u00f3n del n\u00facleo en la direcci\u00f3n virtual 00040008000005f4 [ 31.684627] Informaci\u00f3n de aborto de memoria: [ 31.687446] ESR = 0x0000000096000004 [ 31.704614] EC = 0x25: DABT (EL actual), IL = 32 bits [ 31.720663] SET = 0, FnV = 0 [ 31.723729] EA = 0, S1PTW = 0 [ 31.740617] FSC = 0x04: error de traducci\u00f3n de nivel 0 [ 31.756624] Informaci\u00f3n de aborto de datos: [ 31.759508] ISV = 0, ISS = 0x00000004 [ 31.776705] CM = 0, WnR = 0 [ 31.779695] [00040008000005f4] direcci\u00f3n entre los rangos de direcciones del usuario y del n\u00facleo [ 31.808644] Error interno: Oops: 0000000096000004 [#1] PREEMPT SMP [ 31.814928] Modules linked in: wlcore_sdio wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10dif_ce phy_gmii_sel ti_am65_cpsw_nuss(-) sch_fq_codel ipv6 [ 31.828776] CPU: 0 PID: 1026 Comm: modprobe Not tainted 6.1.0-rc2-00012-gfabfcf7dafdb-dirty #160 [ 31.837547] Hardware name: Texas Instruments AM625 (DT) [ 31.842760] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.849709] pc : phy_stop+0x18/0xf8 [ 31.853202] lr : phylink_stop+0x38/0xf8 [ 31.857031] sp : ffff80000a0839f0 [ 31.860335] x29: ffff80000a0839f0 x28: ffff000000de1c80 x27: 0000000000000000 [ 31.867462] x26: 0000000000000000 x25: 0000000000000000 x24: ffff80000a083b98 [ 31.874589] x23: 0000000000000800 x22: 0000000000000001 x21: ffff000001bfba90 [ 31.881715] x20: ffff0000015ee000 x19: 0004000800000200 x18: 0000000000000000 [ 31.888842] x17: ffff800076c45000 x16: ffff800008004000 x15: 000058e39660b106 [ 31.895969] x14: 0000000000000144 x13: 0000000000000144 x12: 0000000000000000 [ 31.903095] x11: 000000000000275f x10: 00000000000009e0 x9 : ffff80000a0837d0 [ 31.910222] x8 : ffff000000de26c0 x7 : ffff00007fbd6540 x6 : ffff00007fbd64c0 [ 31.917349] x5 : ffff00007fbd0b10 x4 : ffff00007fbd0b10 x3 : ffff00007fbd3920 [ 31.924476] x2 : d0a07fcff8b8d500 x1 : 0000000000000000 x0 : 0004000800000200 [ 31.931603] Call trace: [ 31.934042] phy_stop+0x18/0xf8 [ 31.937177] phylink_stop+0x38/0xf8 [ 31.940657] am65_cpsw_nuss_ndo_slave_stop+0x28/0x1e0 [ti_am65_cpsw_nuss] [ 31.947452] __dev_close_many+0xa4/0x140 [ 31.951371] dev_close_many+0x84/0x128 [ 31.955115] unregister_netdevice_many+0x130/0x6d0 [ 31.959897] unregister_netdevice_queue+0x94/0xd8 [ 31.964591] unregister_netdev+0x24/0x38 [ 31.968504] am65_cpsw_nuss_cleanup_ndev.isra.0+0x48/0x70 [ti_am65_cpsw_nuss] [ 31.975637] am65_cpsw_nuss_remove+0x58/0xf8 [ti_am65_cpsw_nuss] "
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49848.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49848",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:08.327",
"lastModified": "2025-05-01T15:16:08.327",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nphy: qcom-qmp-combo: fix NULL-deref on runtime resume\n\nCommit fc64623637da (\"phy: qcom-qmp-combo,usb: add support for separate\nPCS_USB region\") started treating the PCS_USB registers as potentially\nseparate from the PCS registers but used the wrong base when no PCS_USB\noffset has been provided.\n\nFix the PCS_USB base used at runtime resume to prevent dereferencing a\nNULL pointer on platforms that do not provide a PCS_USB offset (e.g.\nSC7180)."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: qcom-qmp-combo: correcci\u00f3n de la desreferencia de NULL al reanudar la ejecuci\u00f3n. El commit fc64623637da (\"phy: qcom-qmp-combo,usb: a\u00f1adir compatibilidad con la regi\u00f3n PCS_USB independiente\") comenz\u00f3 a tratar los registros PCS_USB como potencialmente independientes de los registros PCS, pero utilizaba la base incorrecta cuando no se proporcionaba un desplazamiento PCS_USB. Se corrigi\u00f3 la base PCS_USB utilizada al reanudar la ejecuci\u00f3n para evitar la desreferenciaci\u00f3n de un puntero NULL en plataformas que no proporcionan un desplazamiento PCS_USB (p. ej., SC7180)."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49849.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49849",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:08.450",
"lastModified": "2025-05-01T15:16:08.450",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix match incorrectly in dev_args_match_device\n\nsyzkaller found a failed assertion:\n\n assertion failed: (args->devid != (u64)-1) || args->missing, in fs/btrfs/volumes.c:6921\n\nThis can be triggered when we set devid to (u64)-1 by ioctl. In this\ncase, the match of devid will be skipped and the match of device may\nsucceed incorrectly.\n\nPatch 562d7b1512f7 introduced this function which is used to match device.\nThis function contains two matching scenarios, we can distinguish them by\nchecking the value of args->missing rather than check whether args->devid\nand args->uuid is default value."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: correcci\u00f3n de coincidencia incorrecta en dev_args_match_device syzkaller encontr\u00f3 una aserci\u00f3n fallida: assertion failed: (args-&gt;devid != (u64)-1) || args-&gt;missing, en fs/btrfs/volumes.c:6921 Esto puede activarse cuando configuramos devid en (u64)-1 mediante ioctl. En este caso, se omitir\u00e1 la coincidencia de devid y la coincidencia de dispositivo puede tener \u00e9xito incorrectamente. El parche 562d7b1512f7 introdujo esta funci\u00f3n que se utiliza para hacer coincidir dispositivos. Esta funci\u00f3n contiene dos escenarios de coincidencia; podemos distinguirlos comprobando el valor de args-&gt;missing en lugar de comprobar si args-&gt;devid y args-&gt;uuid son los valores predeterminados."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49850.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49850",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:08.567",
"lastModified": "2025-05-01T15:16:08.567",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix deadlock in nilfs_count_free_blocks()\n\nA semaphore deadlock can occur if nilfs_get_block() detects metadata\ncorruption while locating data blocks and a superblock writeback occurs at\nthe same time:\n\ntask 1 task 2\n------ ------\n* A file operation *\nnilfs_truncate()\n nilfs_get_block()\n down_read(rwsem A) <--\n nilfs_bmap_lookup_contig()\n ... generic_shutdown_super()\n nilfs_put_super()\n * Prepare to write superblock *\n down_write(rwsem B) <--\n nilfs_cleanup_super()\n * Detect b-tree corruption * nilfs_set_log_cursor()\n nilfs_bmap_convert_error() nilfs_count_free_blocks()\n __nilfs_error() down_read(rwsem A) <--\n nilfs_set_error()\n down_write(rwsem B) <--\n\n *** DEADLOCK ***\n\nHere, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem)\nand then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata\ncorruption, __nilfs_error() is called from nilfs_bmap_convert_error()\ninside the lock section.\n\nSince __nilfs_error() calls nilfs_set_error() unless the filesystem is\nread-only and nilfs_set_error() attempts to writelock rwsem B (=\nnilfs->ns_sem) to write back superblock exclusively, hierarchical lock\nacquisition occurs in the order rwsem A -> rwsem B.\n\nNow, if another task starts updating the superblock, it may writelock\nrwsem B during the lock sequence above, and can deadlock trying to\nreadlock rwsem A in nilfs_count_free_blocks().\n\nHowever, there is actually no need to take rwsem A in\nnilfs_count_free_blocks() because it, within the lock section, only reads\na single integer data on a shared struct with\nnilfs_sufile_get_ncleansegs(). This has been the case after commit\naa474a220180 (\"nilfs2: add local variable to cache the number of clean\nsegments\"), that is, even before this bug was introduced.\n\nSo, this resolves the deadlock problem by just not taking the semaphore in\nnilfs_count_free_blocks()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corregir bloqueo en nilfs_count_free_blocks() Un bloqueo de sem\u00e1foro puede ocurrir si nilfs_get_block() detecta corrupci\u00f3n de metadatos mientras localiza bloques de datos y ocurre una escritura diferida de superbloque al mismo tiempo: tarea 1 tarea 2 ------ ------ * Una operaci\u00f3n de archivo * nilfs_truncate() nilfs_get_block() down_read(rwsem A) &lt;-- nilfs_bmap_lookup_contig() ... generic_shutdown_super() nilfs_put_super() * Preparar para escribir superbloque * down_write(rwsem B) &lt;-- nilfs_cleanup_super() * Detectar corrupci\u00f3n de \u00e1rbol b * nilfs_set_log_cursor() nilfs_bmap_convert_error() nilfs_count_free_blocks() __nilfs_error() down_read(rwsem A) &lt;-- nilfs_set_error() down_write(rwsem B) &lt;-- *** DEADLOCK *** Aqu\u00ed, nilfs_get_block() vuelve a bloquear rwsem A (= NILFS_MDT(dat_inode)-&gt;mi_sem) y luego llama a nilfs_bmap_lookup_contig(), pero si falla debido a la corrupci\u00f3n de metadatos, se llama a __nilfs_error() desde nilfs_bmap_convert_error() dentro de la secci\u00f3n de bloqueo. Dado que __nilfs_error() llama a nilfs_set_error() a menos que el sistema de archivos sea de solo lectura y nilfs_set_error() intente bloquear la escritura de rwsem B (= nilfs-&gt;ns_sem) para reescribir exclusivamente el superbloque, la adquisici\u00f3n del bloqueo jer\u00e1rquico se produce en el orden rwsem A -&gt; rwsem B. Ahora bien, si otra tarea comienza a actualizar el superbloque, puede bloquear la escritura de rwsem B durante la secuencia de bloqueo anterior y puede bloquearse al intentar bloquear la lectura de rwsem A en nilfs_count_free_blocks(). Sin embargo, no es necesario tomar rwsem A en nilfs_count_free_blocks() porque, dentro de la secci\u00f3n de bloqueo, solo lee un \u00fanico dato entero en una estructura compartida con nilfs_sufile_get_ncleansegs(). Esto ha sucedido despu\u00e9s del commit aa474a220180 (\"nilfs2: a\u00f1adir variable local para almacenar en cach\u00e9 el n\u00famero de segmentos limpios\"), incluso antes de que se introdujera este error. Por lo tanto, esto resuelve el problema de interbloqueo simplemente eliminando el sem\u00e1foro en nilfs_count_free_blocks()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49851.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49851",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:08.680",
"lastModified": "2025-05-01T15:16:08.680",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: fix reserved memory setup\n\nCurrently, RISC-V sets up reserved memory using the \"early\" copy of the\ndevice tree. As a result, when trying to get a reserved memory region\nusing of_reserved_mem_lookup(), the pointer to reserved memory regions\nis using the early, pre-virtual-memory address which causes a kernel\npanic when trying to use the buffer's name:\n\n Unable to handle kernel paging request at virtual address 00000000401c31ac\n Oops [#1]\n Modules linked in:\n CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1\n Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)\n epc : string+0x4a/0xea\n ra : vsnprintf+0x1e4/0x336\n epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0\n gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000\n t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20\n s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000\n a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff\n a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff\n s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008\n s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00\n s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002\n s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617\n t5 : ffffffff812f3618 t6 : ffffffff81203d08\n status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d\n [<ffffffff80338936>] vsnprintf+0x1e4/0x336\n [<ffffffff80055ae2>] vprintk_store+0xf6/0x344\n [<ffffffff80055d86>] vprintk_emit+0x56/0x192\n [<ffffffff80055ed8>] vprintk_default+0x16/0x1e\n [<ffffffff800563d2>] vprintk+0x72/0x80\n [<ffffffff806813b2>] _printk+0x36/0x50\n [<ffffffff8068af48>] print_reserved_mem+0x1c/0x24\n [<ffffffff808057ec>] paging_init+0x528/0x5bc\n [<ffffffff808031ae>] setup_arch+0xd0/0x592\n [<ffffffff8080070e>] start_kernel+0x82/0x73c\n\nearly_init_fdt_scan_reserved_mem() takes no arguments as it operates on\ninitial_boot_params, which is populated by early_init_dt_verify(). On\nRISC-V, early_init_dt_verify() is called twice. Once, directly, in\nsetup_arch() if CONFIG_BUILTIN_DTB is not enabled and once indirectly,\nvery early in the boot process, by parse_dtb() when it calls\nearly_init_dt_scan_nodes().\n\nThis first call uses dtb_early_va to set initial_boot_params, which is\nnot usable later in the boot process when\nearly_init_fdt_scan_reserved_mem() is called. On arm64 for example, the\ncorresponding call to early_init_dt_scan_nodes() uses fixmap addresses\nand doesn't suffer the same fate.\n\nMove early_init_fdt_scan_reserved_mem() further along the boot sequence,\nafter the direct call to early_init_dt_verify() in setup_arch() so that\nthe names use the correct virtual memory addresses. The above supposed\nthat CONFIG_BUILTIN_DTB was not set, but should work equally in the case\nwhere it is - unflatted_and_copy_device_tree() also updates\ninitial_boot_params."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: correcci\u00f3n de la configuraci\u00f3n de memoria reservada Actualmente, RISC-V configura la memoria reservada utilizando la copia \"temprana\" del \u00e1rbol de dispositivos. Como resultado, al intentar obtener una regi\u00f3n de memoria reservada usando of_reserved_mem_lookup(), el puntero a las regiones de memoria reservadas usa la direcci\u00f3n anterior a la memoria virtual, lo que causa un p\u00e1nico del kernel al intentar usar el nombre del b\u00fafer: Unable to handle kernel paging request at virtual address 00000000401c31ac Oops [#1] M\u00f3dulos vinculados: CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1 Nombre del hardware: Microchip PolarFire-SoC Icicle Kit (DT) epc : string+0x4a/0xea ra : vsnprintf+0x1e4/0x336 epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0 gp: ffffffff812e0a98 tp: ffffffff8120de40 t0: 0000000000000000 t1: ffffffff81203e28 t2: 7265736572203a46 s0: ffffffff81203c20 s1: ffffffff81203e28 a0: ffffffff81203d22 a1: 0000000000000000 a2: ffffffff81203d08 a3: 0000000081203d21 a4: ffffffffffffffff a5: 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008 s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00 s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 000000000000002 s11: ffffffff80d9821c t3 : ffffffff812f3617 t4: ffffffff812f3617 t5: ffffffff812f3618 t6: ffffffff81203d08 estado: 0000000200000100 direcci\u00f3n incorrecta: 00000000401c31ac causa: 000000000000000d [] vsnprintf+0x1e4/0x336 [] vprintk_store+0xf6/0x344 [] vprintk_emit+0x56/0x192 [] vprintk_default+0x16/0x1e [] vprintk+0x72/0x80 [] _printk+0x36/0x50 [] print_reserved_mem+0x1c/0x24 [] paging_init+0x528/0x5bc [] setup_arch+0xd0/0x592 [] start_kernel+0x82/0x73c early_init_fdt_scan_reserved_mem() no toma argumentos ya que opera en initial_boot_params, que se completa con early_init_dt_verify(). En RISC-V, early_init_dt_verify() se llama dos veces: una directamente, en setup_arch() si CONFIG_BUILTIN_DTB no est\u00e1 habilitado, y otra indirectamente, en una fase muy temprana del proceso de arranque, mediante parse_dtb() al llamar a early_init_dt_scan_nodes(). Esta primera llamada utiliza dtb_early_va para establecer initial_boot_params, que no se puede utilizar posteriormente en el proceso de arranque cuando se llama a early_init_fdt_scan_reserved_mem(). En arm64, por ejemplo, la llamada correspondiente a early_init_dt_scan_nodes() utiliza direcciones fixmap y no sufre el mismo problema. Desplace early_init_fdt_scan_reserved_mem() m\u00e1s adelante en la secuencia de arranque, despu\u00e9s de la llamada directa a early_init_dt_verify() en setup_arch() para que los nombres utilicen las direcciones de memoria virtual correctas. Lo anterior supuso que CONFIG_BUILTIN_DTB no estaba configurado, pero deber\u00eda funcionar igualmente en el caso en que lo est\u00e9: unflatted_and_copy_device_tree() tambi\u00e9n actualiza initial_boot_params."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49852.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49852",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:08.787",
"lastModified": "2025-05-01T15:16:08.787",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: process: fix kernel info leakage\n\nthread_struct's s[12] may contain random kernel memory content, which\nmay be finally leaked to userspace. This is a security hole. Fix it\nby clearing the s[12] array in thread_struct when fork.\n\nAs for kthread case, it's better to clear the s[12] array as well."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: proceso: correcci\u00f3n de fuga de informaci\u00f3n del kernel. El array s[12] de thread_struct puede contener contenido aleatorio de memoria del kernel, que podr\u00eda filtrarse al espacio de usuario. Esto representa una vulnerabilidad de seguridad. Para solucionarlo, borre la matriz s[12] de thread_struct al bifurcar. En el caso de kthread, es recomendable borrar tambi\u00e9n la matriz s[12]."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49853.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49853",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:08.890",
"lastModified": "2025-05-01T15:16:08.890",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: macvlan: fix memory leaks of macvlan_common_newlink\n\nkmemleak reports memory leaks in macvlan_common_newlink, as follows:\n\n ip link add link eth0 name .. type macvlan mode source macaddr add\n <MAC-ADDR>\n\nkmemleak reports:\n\nunreferenced object 0xffff8880109bb140 (size 64):\n comm \"ip\", pid 284, jiffies 4294986150 (age 430.108s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z.....\n 80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk\n backtrace:\n [<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300\n [<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0\n [<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170\n [<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0\n [<ffffffff81b6797e>] macvlan_newlink+0xe/0x20\n [<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50\n [<ffffffff81d98278>] rtnl_newlink+0x48/0x70\n ...\n\nIn the scenario where the macvlan mode is configured as 'source',\nmacvlan_changelink_sources() will be execured to reconfigure list of\nremote source mac addresses, at the same time, if register_netdevice()\nreturn an error, the resource generated by macvlan_changelink_sources()\nis not cleaned up.\n\nUsing this patch, in the case of an error, it will execute\nmacvlan_flush_sources() to ensure that the resource is cleaned up."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: macvlan: corregir fugas de memoria de macvlan_common_newlink kmemleak informa de fugas de memoria en macvlan_common_newlink, como se indica a continuaci\u00f3n: ip link add link eth0 name .. type macvlan mode source macaddr add kmemleak informa: objeto no referenciado 0xffff8880109bb140 (tama\u00f1o 64): comm \"ip\", pid 284, jiffies 4294986150 (edad 430.108s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z..... 80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk seguimiento inverso: [] kmem_cache_alloc_trace+0x1c7/0x300 [] macvlan_hash_add_source+0x45/0xc0 [] macvlan_changelink_sources+0xd7/0x170 [] macvlan_common_newlink+0x38c/0x5a0 [] macvlan_newlink+0xe/0x20 [] __rtnl_newlink+0x7af/0xa50 [] rtnl_newlink+0x48/0x70 ... En el escenario donde el modo macvlan est\u00e1 configurado como 'origen', se ejecutar\u00e1 macvlan_changelink_sources() para reconfigurar la lista de direcciones MAC de origen remoto. Al mismo tiempo, si register_netdevice() devuelve un error, el recurso generado por macvlan_changelink_sources() no se limpia. Con este parche, en caso de error, se ejecutar\u00e1 macvlan_flush_sources() para garantizar que el recurso se limpie."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49854.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49854",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:08.997",
"lastModified": "2025-05-01T15:16:08.997",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmctp: Fix an error handling path in mctp_init()\n\nIf mctp_neigh_init() return error, the routes resources should\nbe released in the error handling path. Otherwise some resources\nleak."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mctp: Se corrige una ruta de gesti\u00f3n de errores en mctp_init(). Si mctp_neigh_init() devuelve un error, los recursos de las rutas deben liberarse en la ruta de gesti\u00f3n de errores. De lo contrario, se producen fugas de recursos."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49855.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49855",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:09.090",
"lastModified": "2025-05-01T15:16:09.090",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:53:20.943",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg\n\nipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() to\nobtain the wwan power state configuration from BIOS but is\nnot freeing the acpi_object. The acpi_evaluate_dsm() returned\nacpi_object to be freed.\n\nFree the acpi_object after use."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wwan: iosm: se corrige la p\u00e9rdida de memoria en ipc_pcie_read_bios_cfg. ipc_pcie_read_bios_cfg() utiliza acpi_evaluate_dsm() para obtener la configuraci\u00f3n del estado de energ\u00eda de wwan desde la BIOS, pero no libera acpi_object. Acpi_evaluate_dsm() devolvi\u00f3 acpi_object para su liberaci\u00f3n. Libere acpi_object despu\u00e9s de su uso."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-498xx/CVE-2022-49856.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49856",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-05-01T15:16:09.197",
"lastModified": "2025-05-01T15:16:09.197",
"vulnStatus": "Received",
"lastModified": "2025-05-02T13:52:51.693",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tun: call napi_schedule_prep() to ensure we own a napi\n\nA recent patch exposed another issue in napi_get_frags()\ncaught by syzbot [1]\n\nBefore feeding packets to GRO, and calling napi_complete()\nwe must first grab NAPI_STATE_SCHED.\n\n[1]\nWARNING: CPU: 0 PID: 3612 at net/core/dev.c:6076 napi_complete_done+0x45b/0x880 net/core/dev.c:6076\nModules linked in:\nCPU: 0 PID: 3612 Comm: syz-executor408 Not tainted 6.1.0-rc3-syzkaller-00175-g1118b2049d77 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nRIP: 0010:napi_complete_done+0x45b/0x880 net/core/dev.c:6076\nCode: c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 24 04 00 00 41 89 5d 1c e9 73 fc ff ff e8 b5 53 22 fa <0f> 0b e9 82 fe ff ff e8 a9 53 22 fa 48 8b 5c 24 08 31 ff 48 89 de\nRSP: 0018:ffffc90003c4f920 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000030 RCX: 0000000000000000\nRDX: ffff8880251c0000 RSI: ffffffff875a58db RDI: 0000000000000007\nRBP: 0000000000000001 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffff888072d02628\nR13: ffff888072d02618 R14: ffff888072d02634 R15: 0000000000000000\nFS: 0000555555f13300(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055c44d3892b8 CR3: 00000000172d2000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n<TASK>\nnapi_complete include/linux/netdevice.h:510 [inline]\ntun_get_user+0x206d/0x3a60 drivers/net/tun.c:1980\ntun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2027\ncall_write_iter include/linux/fs.h:2191 [inline]\ndo_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735\ndo_iter_write+0x182/0x700 fs/read_write.c:861\nvfs_writev+0x1aa/0x630 fs/read_write.c:934\ndo_writev+0x133/0x2f0 fs/read_write.c:977\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f37021a3c19"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tun: llamar a napi_schedule_prep() para asegurarnos de que poseemos un napi Un parche reciente expuso otro problema en napi_get_frags() detectado por syzbot [1] Antes de alimentar paquetes a GRO y llamar a napi_complete(), primero debemos obtener NAPI_STATE_SCHED. [1] ADVERTENCIA: CPU: 0 PID: 3612 en net/core/dev.c:6076 napi_complete_done+0x45b/0x880 net/core/dev.c:6076 M\u00f3dulos vinculados: CPU: 0 PID: 3612 Comm: syz-executor408 No contaminado 6.1.0-rc3-syzkaller-00175-g1118b2049d77 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 RIP: 0010:napi_complete_done+0x45b/0x880 net/core/dev.c:6076 C\u00f3digo: c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 24 04 00 00 41 89 5d 1c e9 73 fc ff ff e8 b5 53 22 fa &lt;0f&gt; 0b e9 82 fe ff ff e8 a9 53 22 fa 48 8b 5c 24 08 31 ff 48 89 de RSP: 0018:ffffc90003c4f920 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000030 RCX: 000000000000000 RDX: ffff8880251c0000 RSI: ffffffff875a58db RDI: 0000000000000007 RBP: 0000000000000001 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff888072d02628 R13: ffff888072d02618 R14: ffff888072d02634 R15: 0000000000000000 FS: 0000555555f13300(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055c44d3892b8 CR3: 00000000172d2000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: napi_complete include/linux/netdevice.h:510 [inline] tun_get_user+0x206d/0x3a60 drivers/net/tun.c:1980 tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2027 call_write_iter include/linux/fs.h:2191 [inline] do_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735 do_iter_write+0x182/0x700 fs/read_write.c:861 vfs_writev+0x1aa/0x630 fs/read_write.c:934 do_writev+0x133/0x2f0 fs/read_write.c:977 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f37021a3c19 "
}
],
"metrics": {},

Some files were not shown because too many files have changed in this diff Show More