admin/nvd-json-data-feeds
1
0
Fork 0
mirror of https://github.com/fkie-cad/nvd-json-data-feeds.git synced 2025-07-09 16:05:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

Auto-Update: 2024-10-23T16:00:54.822569+00:00

Browse Source
This commit is contained in:
cad-safe-bot 2024-10-23 16:03:56 +00:00
parent 5eb6af922f
commit 9dfd72c97e
488 changed files with 6891 additions and 1527 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
CVE-2018/CVE-2018-133xx/CVE-2018-13374.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2018-13374",
"sourceIdentifier": "psirt@fortinet.com",
"published": "2019-01-22T14:29:00.220",
"lastModified": "2024-06-28T14:04:14.410",
"vulnStatus": "Analyzed",
"lastModified": "2024-10-23T14:35:00.903",
"vulnStatus": "Modified",
"cveTags": [],
"cisaExploitAdd": "2022-09-08",
"cisaActionDue": "2022-09-29",
@ -98,6 +98,16 @@
"value": "CWE-732"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-732"
}
]
}
],
"configurations": [

14
CVE-2018/CVE-2018-133xx/CVE-2018-13379.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2018-13379",
"sourceIdentifier": "psirt@fortinet.com",
"published": "2019-06-04T21:29:00.233",
"lastModified": "2024-07-25T14:09:54.960",
"vulnStatus": "Analyzed",
"lastModified": "2024-10-23T14:35:02.830",
"vulnStatus": "Modified",
"cveTags": [],
"cisaExploitAdd": "2021-11-03",
"cisaActionDue": "2022-05-03",
@ -98,6 +98,16 @@
"value": "CWE-22"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-22"
}
]
}
],
"configurations": [

14
CVE-2018/CVE-2018-133xx/CVE-2018-13382.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2018-13382",
"sourceIdentifier": "psirt@fortinet.com",
"published": "2019-06-04T21:29:00.373",
"lastModified": "2024-07-24T17:00:11.230",
"vulnStatus": "Analyzed",
"lastModified": "2024-10-23T14:35:03.977",
"vulnStatus": "Modified",
"cveTags": [],
"cisaExploitAdd": "2022-01-10",
"cisaActionDue": "2022-07-10",
@ -98,6 +98,16 @@
"value": "CWE-863"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-863"
}
]
}
],
"configurations": [

14
CVE-2018/CVE-2018-133xx/CVE-2018-13383.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2018-13383",
"sourceIdentifier": "psirt@fortinet.com",
"published": "2019-05-29T18:29:00.693",
"lastModified": "2021-03-16T15:48:20.167",
"vulnStatus": "Analyzed",
"lastModified": "2024-10-23T14:35:04.847",
"vulnStatus": "Modified",
"cveTags": [],
"cisaExploitAdd": "2022-01-10",
"cisaActionDue": "2022-07-10",
@ -98,6 +98,16 @@
"value": "CWE-787"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-787"
}
]
}
],
"configurations": [

34
CVE-2019/CVE-2019-55xx/CVE-2019-5591.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2019-5591",
"sourceIdentifier": "psirt@fortinet.com",
"published": "2020-08-14T16:15:16.070",
"lastModified": "2021-07-21T11:39:23.747",
"vulnStatus": "Analyzed",
"lastModified": "2024-10-23T14:35:05.617",
"vulnStatus": "Modified",
"cveTags": [],
"cisaExploitAdd": "2021-11-03",
"cisaActionDue": "2022-05-03",
@ -40,6 +40,26 @@
},
"exploitabilityScore": 2.8,
"impactScore": 3.6
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"attackVector": "ADJACENT_NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM"
},
"exploitabilityScore": 2.8,
"impactScore": 3.6
}
],
"cvssMetricV2": [
@ -78,6 +98,16 @@
"value": "CWE-306"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-306"
}
]
}
],
"configurations": [

14
CVE-2021/CVE-2021-245xx/CVE-2021-24566.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2021-24566",
"sourceIdentifier": "contact@wpscan.com",
"published": "2024-01-16T16:15:09.003",
"lastModified": "2024-01-23T20:37:16.450",
"vulnStatus": "Analyzed",
"lastModified": "2024-10-23T15:35:02.310",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
{
@ -49,6 +49,16 @@
"value": "NVD-CWE-Other"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-22"
}
]
}
],
"configurations": [

4
CVE-2021/CVE-2021-441xx/CVE-2021-44168.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2021-44168",
"sourceIdentifier": "psirt@fortinet.com",
"published": "2022-01-04T13:15:07.957",
"lastModified": "2024-10-22T21:35:02.960",
"vulnStatus": "Modified",
"lastModified": "2024-10-23T15:40:23.217",
"vulnStatus": "Analyzed",
"cveTags": [],
"cisaExploitAdd": "2021-12-10",
"cisaActionDue": "2021-12-24",

8
CVE-2022/CVE-2022-238xx/CVE-2022-23861.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-23861",
"sourceIdentifier": "cve@mitre.org",
"published": "2024-10-22T16:15:04.897",
"lastModified": "2024-10-22T19:35:01.570",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Multiple Stored Cross-Site Scripting vulnerabilities were discovered in Y Soft SAFEQ 6 Build 53. Multiple fields in the YSoft SafeQ web application can be used to inject malicious inputs that, due to a lack of output sanitization, result in the execution of arbitrary JS code. These fields can be leveraged to perform XSS attacks on legitimate users accessing the SafeQ web interface."
},
{
"lang": "es",
"value": " Se descubrieron m\u00faltiples vulnerabilidades de cross-site scripting almacenadas en Y Soft SAFEQ 6 Build 53. Se pueden usar varios campos en la aplicaci\u00f3n web YSoft SafeQ para inyectar entradas maliciosas que, debido a la falta de desinfecci\u00f3n de salida, dan como resultado la ejecuci\u00f3n de c\u00f3digo JS arbitrario. Estos campos se pueden aprovechar para realizar ataques XSS a usuarios leg\u00edtimos que acceden a la interfaz web de SafeQ."
}
],
"metrics": {

8
CVE-2022/CVE-2022-238xx/CVE-2022-23862.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-23862",
"sourceIdentifier": "cve@mitre.org",
"published": "2024-10-22T16:15:05.443",
"lastModified": "2024-10-22T19:35:03.463",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "A Local Privilege Escalation issue was discovered in Y Soft SAFEQ 6 Build 53. The SafeQ JMX service running on port 9696 is vulnerable to JMX MLet attacks. Because the service did not enforce authentication and was running under the \"NT Authority\\System\" user, an attacker is able to use the vulnerability to execute arbitrary code and elevate to the system user."
},
{
"lang": "es",
"value": " Se descubri\u00f3 un problema de escalada de privilegios locales en Y Soft SAFEQ 6 Build 53. El servicio JMX de SafeQ que se ejecuta en el puerto 9696 es vulnerable a ataques JMX MLet. Debido a que el servicio no aplicaba la autenticaci\u00f3n y se ejecutaba bajo el usuario \"NT Authority\\System\", un atacante puede usar la vulnerabilidad para ejecutar c\u00f3digo arbitrario y ascender al usuario del sistema."
}
],
"metrics": {

14
CVE-2022/CVE-2022-437xx/CVE-2022-43713.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-43713",
"sourceIdentifier": "cve@mitre.org",
"published": "2023-07-26T14:15:09.930",
"lastModified": "2023-08-04T15:49:03.637",
"vulnStatus": "Analyzed",
"lastModified": "2024-10-23T15:35:06.987",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
{
@ -45,6 +45,16 @@
"value": "CWE-20"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-116"
}
]
}
],
"configurations": [

8
CVE-2022/CVE-2022-489xx/CVE-2022-48946.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48946",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.020",
"lastModified": "2024-10-21T20:15:06.020",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nudf: Fix preallocation discarding at indirect extent boundary\n\nWhen preallocation extent is the first one in the extent block, the\ncode would corrupt extent tree header instead. Fix the problem and use\nudf_delete_aext() for deleting extent to avoid some code duplication."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udf: Se corrige el descarte de preasignaci\u00f3n en el l\u00edmite de extensi\u00f3n indirecta. Cuando la extensi\u00f3n de preasignaci\u00f3n es la primera en el bloque de extensi\u00f3n, el c\u00f3digo corromper\u00eda el encabezado del \u00e1rbol de extensi\u00f3n. Corrija el problema y use udf_delete_aext() para eliminar la extensi\u00f3n y evitar la duplicaci\u00f3n de c\u00f3digo."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48947.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48947",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.150",
"lastModified": "2024-10-21T20:15:06.150",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix u8 overflow\n\nBy keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases\nmultiple times and eventually it will wrap around the maximum number\n(i.e., 255).\nThis patch prevents this by adding a boundary check with\nL2CAP_MAX_CONF_RSP\n\nBtmon log:\nBluetooth monitor ver 5.64\n= Note: Linux version 6.1.0-rc2 (x86_64) 0.264594\n= Note: Bluetooth subsystem version 2.22 0.264636\n@ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191\n= New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604\n@ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741\n= Open Index: 00:00:00:00:00:00 [hci0] 13.900426\n(...)\n> ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106\n invalid packet size (12 != 1033)\n 08 00 01 00 02 01 04 00 01 10 ff ff ............\n> ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561\n invalid packet size (14 != 1547)\n 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@.....\n> ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390\n invalid packet size (16 != 2061)\n 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@.......\n> ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932\n invalid packet size (16 != 2061)\n 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@.......\n= bluetoothd: Bluetooth daemon 5.43 14.401828\n> ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753\n invalid packet size (12 != 1033)\n 08 00 01 00 04 01 04 00 40 00 00 00 ........@..."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: Corregir desbordamiento de u8 Al seguir enviando paquetes L2CAP_CONF_REQ, chan->num_conf_rsp aumenta varias veces y eventualmente alcanzar\u00e1 el n\u00famero m\u00e1ximo (es decir, 255). Este parche evita esto a\u00f1adiendo una comprobaci\u00f3n de los l\u00edmites con L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Nota: Linux versi\u00f3n 6.1.0-rc2 (x86_64) 0.264594 = Nota: Subsistema Bluetooth versi\u00f3n 2.22 0.264636 @ MGMT Open: btmon (privilegiado) versi\u00f3n 1.22 {0x0001} 0.272191 = Nuevo \u00edndice: 00:00:00:00:00:00 (Principal,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privilegiado) versi\u00f3n 2.22 {0x0002} 13.890741 = Abierto \u00cdndice: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Manejar 200 indicadores 0x00 dlen 1033 #32 [hci0] 14.273106 tama\u00f1o de paquete no v\u00e1lido (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Manejar 200 indicadores 0x00 dlen 1547 #33 [hci0] 14.273561 tama\u00f1o de paquete no v\u00e1lido (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Manejar 200 indicadores 0x00 dlen 2061 #34 [hci0] 14.274390 tama\u00f1o de paquete no v\u00e1lido (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Manejar 200 indicadores 0x00 dlen 2061 #35 [hci0] 14.274932 tama\u00f1o de paquete no v\u00e1lido (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Daemon Bluetooth 5.43 14.401828 > ACL Data RX: Manejar 200 indicadores 0x00 dlen 1033 #36 [hci0] 14.275753 tama\u00f1o de paquete no v\u00e1lido (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@..."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48948.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48948",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.230",
"lastModified": "2024-10-21T20:15:06.230",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: uvc: Prevent buffer overflow in setup handler\n\nSetup function uvc_function_setup permits control transfer\nrequests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE),\ndata stage handler for OUT transfer uses memcpy to copy req->actual\nbytes to uvc_event->data.data array of size 60. This may result\nin an overflow of 4 bytes."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: uvc: Evitar desbordamiento de b\u00fafer en el controlador de configuraci\u00f3n La funci\u00f3n de configuraci\u00f3n uvc_function_setup permite solicitudes de transferencia de control con hasta 64 bytes de payload (UVC_MAX_REQUEST_SIZE), el controlador de etapa de datos para transferencia OUT usa memcpy para copiar req->actual bytes a la matriz uvc_event->data.data de tama\u00f1o 60. Esto puede resultar en un desbordamiento de 4 bytes."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48949.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48949",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.337",
"lastModified": "2024-10-21T20:15:06.337",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nigb: Initialize mailbox message for VF reset\n\nWhen a MAC address is not assigned to the VF, that portion of the message\nsent to the VF is not set. The memory, however, is allocated from the\nstack meaning that information may be leaked to the VM. Initialize the\nmessage buffer to 0 so that no information is passed to the VM in this\ncase."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: inicializar mensaje de buz\u00f3n para restablecer VF Cuando no se asigna una direcci\u00f3n MAC a la VF, esa parte del mensaje enviado a la VF no se configura. Sin embargo, la memoria se asigna desde la pila, lo que significa que la informaci\u00f3n puede filtrarse a la VM. Inicialice el b\u00fafer de mensajes a 0 para que no se pase informaci\u00f3n a la VM en este caso."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48950.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48950",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.440",
"lastModified": "2024-10-21T20:15:06.440",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix perf_pending_task() UaF\n\nPer syzbot it is possible for perf_pending_task() to run after the\nevent is free()'d. There are two related but distinct cases:\n\n - the task_work was already queued before destroying the event;\n - destroying the event itself queues the task_work.\n\nThe first cannot be solved using task_work_cancel() since\nperf_release() itself might be called from a task_work (____fput),\nwhich means the current->task_works list is already empty and\ntask_work_cancel() won't be able to find the perf_pending_task()\nentry.\n\nThe simplest alternative is extending the perf_event lifetime to cover\nthe task_work.\n\nThe second is just silly, queueing a task_work while you know the\nevent is going away makes no sense and is easily avoided by\nre-arranging how the event is marked STATE_DEAD and ensuring it goes\nthrough STATE_OFF on the way down."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: Fix perf_pending_task() UaF Por syzbot es posible que perf_pending_task() se ejecute despu\u00e9s de que el evento sea free(). Hay dos casos relacionados pero distintos: - el task_work ya estaba en cola antes de destruir el evento; - destruir el evento en s\u00ed mismo pone en cola el task_work. El primero no se puede resolver usando task_work_cancel() ya que perf_release() en s\u00ed mismo podr\u00eda ser llamado desde un task_work (____fput), lo que significa que la lista current->task_works ya est\u00e1 vac\u00eda y task_work_cancel() no podr\u00e1 encontrar la entrada perf_pending_task(). La alternativa m\u00e1s simple es extender la duraci\u00f3n de perf_event para cubrir el task_work. El segundo es simplemente una tonter\u00eda, poner en cola una tarea_trabajo mientras sabes que el evento va a desaparecer no tiene sentido y se evita f\u00e1cilmente reorganizando c\u00f3mo se marca el evento como STATE_DEAD y asegur\u00e1ndose de que pase por STATE_OFF en el camino hacia abajo."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48951.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48951",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.530",
"lastModified": "2024-10-21T20:15:06.530",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()\n\nThe bounds checks in snd_soc_put_volsw_sx() are only being applied to the\nfirst channel, meaning it is possible to write out of bounds values to the\nsecond channel in stereo controls. Add appropriate checks."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: ops: Verificar l\u00edmites para el segundo canal en snd_soc_put_volsw_sx() Las comprobaciones de los l\u00edmites en snd_soc_put_volsw_sx() solo se aplican al primer canal, lo que significa que es posible escribir valores fuera de los l\u00edmites en el segundo canal en controles est\u00e9reo. Agregue las comprobaciones adecuadas."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48952.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48952",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.617",
"lastModified": "2024-10-21T20:15:06.617",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: mt7621: Add sentinel to quirks table\n\nCurrent driver is missing a sentinel in the struct soc_device_attribute\narray, which causes an oops when assessed by the\nsoc_device_match(mt7621_pcie_quirks_match) call.\n\nThis was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr\nwas fixed to register the SOC as a device, in:\n\ncommit 7c18b64bba3b (\"mips: ralink: mt7621: do not use kzalloc too early\")\n\nFix it by adding the required sentinel."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: mt7621: Agregar centinela a la tabla de peculiaridades Al controlador actual le falta un centinela en la matriz struct soc_device_attribute, lo que provoca un error cuando se eval\u00faa mediante la llamada soc_device_match(mt7621_pcie_quirks_match). Esto solo se expuso una vez que se arregl\u00f3 CONFIG_SOC_MT7621 mt7621 soc_dev_attr para registrar el SOC como un dispositivo, en: commit 7c18b64bba3b (\"mips: ralink: mt7621: no use kzalloc demasiado pronto\") Arr\u00e9glelo agregando el centinela requerido."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48953.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48953",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.700",
"lastModified": "2024-10-21T20:15:06.700",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtc: cmos: Fix event handler registration ordering issue\n\nBecause acpi_install_fixed_event_handler() enables the event\nautomatically on success, it is incorrect to call it before the\nhandler routine passed to it is ready to handle events.\n\nUnfortunately, the rtc-cmos driver does exactly the incorrect thing\nby calling cmos_wake_setup(), which passes rtc_handler() to\nacpi_install_fixed_event_handler(), before cmos_do_probe(), because\nrtc_handler() uses dev_get_drvdata() to get to the cmos object\npointer and the driver data pointer is only populated in\ncmos_do_probe().\n\nThis leads to a NULL pointer dereference in rtc_handler() on boot\nif the RTC fixed event happens to be active at the init time.\n\nTo address this issue, change the initialization ordering of the\ndriver so that cmos_wake_setup() is always called after a successful\ncmos_do_probe() call.\n\nWhile at it, change cmos_pnp_probe() to call cmos_do_probe() after\nthe initial if () statement used for computing the IRQ argument to\nbe passed to cmos_do_probe() which is cleaner than calling it in\neach branch of that if () (local variable \"irq\" can be of type int,\nbecause it is passed to that function as an argument of type int).\n\nNote that commit 6492fed7d8c9 (\"rtc: rtc-cmos: Do not check\nACPI_FADT_LOW_POWER_S0\") caused this issue to affect a larger number\nof systems, because previously it only affected systems with\nACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that\ncommit."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: cmos: Fix event handler registration ordering issue Debido a que acpi_install_fixed_event_handler() habilita el evento autom\u00e1ticamente en caso de \u00e9xito, es incorrecto llamarlo antes de que la rutina del controlador que se le pasa est\u00e9 lista para manejar eventos. Desafortunadamente, el controlador rtc-cmos hace exactamente lo incorrecto al llamar a cmos_wake_setup(), que pasa rtc_handler() a acpi_install_fixed_event_handler(), antes de cmos_do_probe(), porque rtc_handler() usa dev_get_drvdata() para llegar al puntero del objeto cmos y el puntero de datos del controlador solo se completa en cmos_do_probe(). Esto conduce a una desreferencia de puntero NULL en rtc_handler() en el arranque si el evento RTC fixed est\u00e1 activo en el momento de inicializaci\u00f3n. Para solucionar este problema, cambie el orden de inicializaci\u00f3n del controlador de modo que cmos_wake_setup() siempre se llame despu\u00e9s de una llamada a cmos_do_probe() exitosa. Mientras tanto, cambie cmos_pnp_probe() para llamar a cmos_do_probe() despu\u00e9s de la declaraci\u00f3n if () inicial utilizada para calcular el argumento IRQ que se pasar\u00e1 a cmos_do_probe(), lo que es m\u00e1s limpio que llamarlo en cada rama de ese if () (la variable local \"irq\" puede ser de tipo int, porque se pasa a esa funci\u00f3n como un argumento de tipo int). Tenga en cuenta que el commit 6492fed7d8c9 (\"rtc: rtc-cmos: No marque ACPI_FADT_LOW_POWER_S0\") provoc\u00f3 que este problema afectara a una mayor cantidad de sistemas, porque anteriormente solo afectaba a los sistemas con ACPI_FADT_LOW_POWER_S0 configurado, pero est\u00e1 presente independientemente de esa confirmaci\u00f3n."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48954.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48954",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.783",
"lastModified": "2024-10-21T20:15:06.783",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/qeth: fix use-after-free in hsci\n\nKASAN found that addr was dereferenced after br2dev_event_work was freed.\n\n==================================================================\nBUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0\nRead of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540\nCPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1\nHardware name: IBM 8561 T01 703 (LPAR)\nWorkqueue: 0.0.8000_event qeth_l2_br2dev_worker\nCall Trace:\n [<000000016944d4ce>] dump_stack_lvl+0xc6/0xf8\n [<000000016942cd9c>] print_address_description.constprop.0+0x34/0x2a0\n [<000000016942d118>] print_report+0x110/0x1f8\n [<0000000167a7bd04>] kasan_report+0xfc/0x128\n [<000000016938d79a>] qeth_l2_br2dev_worker+0x5ba/0x6b0\n [<00000001673edd1e>] process_one_work+0x76e/0x1128\n [<00000001673ee85c>] worker_thread+0x184/0x1098\n [<000000016740718a>] kthread+0x26a/0x310\n [<00000001672c606a>] __ret_from_fork+0x8a/0xe8\n [<00000001694711da>] ret_from_fork+0xa/0x40\nAllocated by task 108338:\n kasan_save_stack+0x40/0x68\n kasan_set_track+0x36/0x48\n __kasan_kmalloc+0xa0/0xc0\n qeth_l2_switchdev_event+0x25a/0x738\n atomic_notifier_call_chain+0x9c/0xf8\n br_switchdev_fdb_notify+0xf4/0x110\n fdb_notify+0x122/0x180\n fdb_add_entry.constprop.0.isra.0+0x312/0x558\n br_fdb_add+0x59e/0x858\n rtnl_fdb_add+0x58a/0x928\n rtnetlink_rcv_msg+0x5f8/0x8d8\n netlink_rcv_skb+0x1f2/0x408\n netlink_unicast+0x570/0x790\n netlink_sendmsg+0x752/0xbe0\n sock_sendmsg+0xca/0x110\n ____sys_sendmsg+0x510/0x6a8\n ___sys_sendmsg+0x12a/0x180\n __sys_sendmsg+0xe6/0x168\n __do_sys_socketcall+0x3c8/0x468\n do_syscall+0x22c/0x328\n __do_syscall+0x94/0xf0\n system_call+0x82/0xb0\nFreed by task 540:\n kasan_save_stack+0x40/0x68\n kasan_set_track+0x36/0x48\n kasan_save_free_info+0x4c/0x68\n ____kasan_slab_free+0x14e/0x1a8\n __kasan_slab_free+0x24/0x30\n __kmem_cache_free+0x168/0x338\n qeth_l2_br2dev_worker+0x154/0x6b0\n process_one_work+0x76e/0x1128\n worker_thread+0x184/0x1098\n kthread+0x26a/0x310\n __ret_from_fork+0x8a/0xe8\n ret_from_fork+0xa/0x40\nLast potentially related work creation:\n kasan_save_stack+0x40/0x68\n __kasan_record_aux_stack+0xbe/0xd0\n insert_work+0x56/0x2e8\n __queue_work+0x4ce/0xd10\n queue_work_on+0xf4/0x100\n qeth_l2_switchdev_event+0x520/0x738\n atomic_notifier_call_chain+0x9c/0xf8\n br_switchdev_fdb_notify+0xf4/0x110\n fdb_notify+0x122/0x180\n fdb_add_entry.constprop.0.isra.0+0x312/0x558\n br_fdb_add+0x59e/0x858\n rtnl_fdb_add+0x58a/0x928\n rtnetlink_rcv_msg+0x5f8/0x8d8\n netlink_rcv_skb+0x1f2/0x408\n netlink_unicast+0x570/0x790\n netlink_sendmsg+0x752/0xbe0\n sock_sendmsg+0xca/0x110\n ____sys_sendmsg+0x510/0x6a8\n ___sys_sendmsg+0x12a/0x180\n __sys_sendmsg+0xe6/0x168\n __do_sys_socketcall+0x3c8/0x468\n do_syscall+0x22c/0x328\n __do_syscall+0x94/0xf0\n system_call+0x82/0xb0\nSecond to last potentially related work creation:\n kasan_save_stack+0x40/0x68\n __kasan_record_aux_stack+0xbe/0xd0\n kvfree_call_rcu+0xb2/0x760\n kernfs_unlink_open_file+0x348/0x430\n kernfs_fop_release+0xc2/0x320\n __fput+0x1ae/0x768\n task_work_run+0x1bc/0x298\n exit_to_user_mode_prepare+0x1a0/0x1a8\n __do_syscall+0x94/0xf0\n system_call+0x82/0xb0\nThe buggy address belongs to the object at 00000000fdcea400\n which belongs to the cache kmalloc-96 of size 96\nThe buggy address is located 64 bytes inside of\n 96-byte region [00000000fdcea400, 00000000fdcea460)\nThe buggy address belongs to the physical page:\npage:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea\nflags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff)\nraw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00\nraw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000\npage dumped because: kasan: bad access detected\nMemory state around the buggy address:\n 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n 00000000fdcea380: fb fb fb fb fb fb f\n---truncated---"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/qeth: se corrige el use after free en hsci KASAN descubri\u00f3 que addr fue desreferenciado despu\u00e9s de que se liber\u00f3 br2dev_event_work. ===================================================================== ERROR: KASAN: use after free en qeth_l2_br2dev_worker+0x5ba/0x6b0 Lectura de tama\u00f1o 1 en la direcci\u00f3n 00000000fdcea440 por la tarea kworker/u760:4/540 CPU: 17 PID: 540 Comm: kworker/u760:4 Contaminado: GE 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1 Nombre del hardware: IBM 8561 T01 703 (LPAR) Cola de trabajo: 0.0.8000_evento qeth_l2_br2dev_worker Seguimiento de llamadas: [&lt;000000016944d4ce&gt;] nivel_pila_volcado+0xc6/0xf8 [&lt;000000016942cd9c&gt;] descripci\u00f3n_direcci\u00f3n_impresi\u00f3n.constprop.0+0x34/0x2a0 [&lt;000000016942d118&gt;] informe_impresi\u00f3n+0x110/0x1f8 [&lt;0000000167a7bd04&gt;] informe_kasan+0xfc/0x128 [&lt;000000016938d79a&gt;] qeth_l2_br2dev_worker+0x5ba/0x6b0 [&lt;00000001673edd1e&gt;] proceso_uno_trabajo+0x76e/0x1128 [&lt;00000001673ee85c&gt;] subproceso_trabajador+0x184/0x1098 [&lt;000000016740718a&gt;] subproceso_k+0x26a/0x310 [&lt;00000001672c606a&gt;] __ret_from_fork+0x8a/0xe8 [&lt;00000001694711da&gt;] ret_from_fork+0xa/0x40 Asignado por la tarea 108338: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 __kasan_kmalloc+0xa0/0xc0 qeth_l2_switchdev_event+0x25a/0x738 cadena_de_llamadas_de_notificador_at\u00f3mico+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 llamada_sistema+0x82/0xb0 Liberado por la tarea 540: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 kasan_save_free_info+0x4c/0x68 ____kasan_slab_free+0x14e/0x1a8 __kasan_slab_free+0x24/0x30 __kmem_cache_free+0x168/0x338 qeth_l2_br2dev_worker+0x154/0x6b0 process_one_work+0x76e/0x1128 worker_thread+0x184/0x1098 kthread+0x26a/0x310 __ret_from_fork+0x8a/0xe8 ret_from_fork+0xa/0x40 \u00daltima creaci\u00f3n de trabajo potencialmente relacionada: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 insert_work+0x56/0x2e8 __queue_work+0x4ce/0xd10 queue_work_on+0xf4/0x100 qeth_l2_switchdev_event+0x520/0x738 cadena de llamada de notificador at\u00f3mico+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Pen\u00faltima creaci\u00f3n de trabajo potencialmente relacionado: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 kvfree_call_rcu+0xb2/0x760 kernfs_unlink_open_file+0x348/0x430 kernfs_fop_release+0xc2/0x320 __fput+0x1ae/0x768 task_work_run+0x1bc/0x298 exit_to_user_mode_prepare+0x1a0/0x1a8 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 La direcci\u00f3n con errores pertenece al objeto en 00000000fdcea400 que pertenece a la cach\u00e9 kmalloc-96 de tama\u00f1o 96 La direcci\u00f3n con errores se encuentra 64 bytes dentro de la regi\u00f3n de 96 bytes [00000000fdcea400, 00000000fdcea460) La direcci\u00f3n con errores pertenece a la p\u00e1gina f\u00edsica: page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 \u00edndice:0x0 pfn:0xfdcea flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff) raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00 raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000 p\u00e1gina volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la direcci\u00f3n con errores: 00000000fdcea300: fb ..."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48955.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48955",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.870",
"lastModified": "2024-10-21T20:15:06.870",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: thunderbolt: fix memory leak in tbnet_open()\n\nWhen tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated in\ntb_xdomain_alloc_out_hopid() is not released. Add\ntb_xdomain_release_out_hopid() to the error path to release ida."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: thunderbolt: se corrige la p\u00e9rdida de memoria en tbnet_open() Cuando tb_ring_alloc_rx() fallo en tbnet_open(), no se libera el ida asignado en tb_xdomain_alloc_out_hopid(). Agregue tb_xdomain_release_out_hopid() a la ruta de error para liberar el ida."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48956.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48956",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:06.973",
"lastModified": "2024-10-21T20:15:06.973",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: avoid use-after-free in ip6_fragment()\n\nBlamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.\n\nIt seems to not be always true, at least for UDP stack.\n\nsyzbot reported:\n\nBUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]\nBUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951\nRead of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618\n\nCPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:284 [inline]\n print_report+0x15e/0x45d mm/kasan/report.c:395\n kasan_report+0xbf/0x1f0 mm/kasan/report.c:495\n ip6_dst_idev include/net/ip6_fib.h:245 [inline]\n ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951\n __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]\n ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206\n NF_HOOK_COND include/linux/netfilter.h:291 [inline]\n ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227\n dst_output include/net/dst.h:445 [inline]\n ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161\n ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966\n udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286\n udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313\n udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606\n inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg+0xd3/0x120 net/socket.c:734\n sock_write_iter+0x295/0x3d0 net/socket.c:1108\n call_write_iter include/linux/fs.h:2191 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x9ed/0xdd0 fs/read_write.c:584\n ksys_write+0x1ec/0x250 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7fde3588c0d9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9\nRDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a\nRBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000\n </TASK>\n\nAllocated by task 7618:\n kasan_save_stack+0x22/0x40 mm/kasan/common.c:45\n kasan_set_track+0x25/0x30 mm/kasan/common.c:52\n __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325\n kasan_slab_alloc include/linux/kasan.h:201 [inline]\n slab_post_alloc_hook mm/slab.h:737 [inline]\n slab_alloc_node mm/slub.c:3398 [inline]\n slab_alloc mm/slub.c:3406 [inline]\n __kmem_cache_alloc_lru mm/slub.c:3413 [inline]\n kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422\n dst_alloc+0x14a/0x1f0 net/core/dst.c:92\n ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344\n ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]\n rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]\n ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254\n pol_lookup_func include/net/ip6_fib.h:582 [inline]\n fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121\n ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625\n ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638\n ip6_route_output include/net/ip6_route.h:98 [inline]\n ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092\n ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222\n ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260\n udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554\n inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665\n sock_sendmsg_nosec n\n---truncated---"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evitar el use after free en ip6_fragment(). el commit culpable afirmaba que rcu_read_lock() estaba retenido por los llamadores de ip6_fragment(). Parece que no siempre es cierto, al menos para la pila UDP. syzbot inform\u00f3: ERROR: KASAN: use after free en ip6_dst_idev include/net/ip6_fib.h:245 [en l\u00ednea] ERROR: KASAN: use after free en ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 Lectura de tama\u00f1o 8 en la direcci\u00f3n ffff88801d403e80 por la tarea syz-executor.3/7618 CPU: 1 PID: 7618 Comm: syz-executor.3 No contaminado 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en l\u00ednea] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 imprimir_descripci\u00f3n_de_direcci\u00f3n mm/kasan/report.c:284 [en l\u00ednea] imprimir_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 ip6_dst_idev include/net/ip6_fib.h:245 [en l\u00ednea] ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 __ip6_finish_output net/ipv6/ip6_output.c:193 [en l\u00ednea] ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND incluir/linux/netfilter.h:291 [en l\u00ednea] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output incluir/net/dst.h:445 [en l\u00ednea] ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [en l\u00ednea] sock_sendmsg+0xd3/0x120 net/socket.c:734 sock_write_iter+0x295/0x3d0 net/socket.c:1108 call_write_iter include/linux/fs.h:2191 [en l\u00ednea] new_sync_write fs/read_write.c:491 [en l\u00ednea] vfs_write+0x9ed/0xdd0 fs/read_write.c:584 ksys_write+0x1ec/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fde3588c0d9 C\u00f3digo: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9 RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000 R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000 Asignado por la tarea 7618: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325 kasan_slab_alloc include/linux/kasan.h:201 [en l\u00ednea] gancho_alloc_poste_losa mm/slab.h:737 [en l\u00ednea] nodo_alloc_losa mm/slub.c:3398 [en l\u00ednea] losa_alloc mm/slub.c:3406 [en l\u00ednea] __kmem_cache_alloc_lru mm/slub.c:3413 [en l\u00ednea] kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422 dst_alloc+0x14a/0x1f0 net/core/dst.c:92 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [en l\u00ednea] rt6_make_pcpu_route net/ipv6/route.c:1417 [en l\u00ednea] ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254 pol_lookup_func include/net/ip6_fib.h:582 [en l\u00ednea] fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625 banderas de salida de ruta ip6+0x76/0x320 red/ipv6/route.c:2638 salida de ruta ip6 incluir/red/ip6_route.h:98 [en l\u00ednea] cola de b\u00fasqueda de dst ip6+0x5ab/0x1620 red/ipv6/ip6_output.c:1092 flujo de b\u00fasqueda de dst ip6+0x90/0x1d0 red/ipv6/ip6_output.c:1222 flujo de b\u00fasqueda de dst ip6_sk+0x553/0x980 red/ipv6/ip6_output.c:1260 env\u00edo de mensajes de env\u00edo udpv6+0x151d/0x2c80 red/ipv6/udp.c:1554 ---truncado---"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48957.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48957",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:07.090",
"lastModified": "2024-10-21T20:15:07.090",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove()\n\nThe cmd_buff needs to be freed when error happened in\ndpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dpaa2-switch: corrige p\u00e9rdida de memoria en dpaa2_switch_acl_entry_add() y dpaa2_switch_acl_entry_remove(). Es necesario liberar cmd_buff cuando ocurre un error en dpaa2_switch_acl_entry_add() y dpaa2_switch_acl_entry_remove()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48958.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48958",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:07.270",
"lastModified": "2024-10-21T20:15:07.270",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nethernet: aeroflex: fix potential skb leak in greth_init_rings()\n\nThe greth_init_rings() function won't free the newly allocated skb when\ndma_mapping_error() returns error, so add dev_kfree_skb() to fix it.\n\nCompile tested only."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ethernet: aeroflex: se corrige una posible fuga de skb en greth_init_rings() La funci\u00f3n greth_init_rings() no liberar\u00e1 el skb reci\u00e9n asignado cuando dma_mapping_error() devuelva un error, por lo que se debe agregar dev_kfree_skb() para corregirlo. Solo se prob\u00f3 la compilaci\u00f3n."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48959.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48959",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:07.460",
"lastModified": "2024-10-21T20:15:07.460",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions()\n\nWhen dsa_devlink_region_create failed in sja1105_setup_devlink_regions(),\npriv->regions is not released."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: sja1105: se corrige una p\u00e9rdida de memoria en sja1105_setup_devlink_regions() Cuando dsa_devlink_region_create fallo en sja1105_setup_devlink_regions(), priv-&gt;regions no se libera."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48960.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48960",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:07.663",
"lastModified": "2024-10-21T20:15:07.663",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hisilicon: Fix potential use-after-free in hix5hd2_rx()\n\nThe skb is delivered to napi_gro_receive() which may free it, after\ncalling this, dereferencing skb may trigger use-after-free."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hisilicon: Se corrige un posible use after free en hix5hd2_rx() El skb se env\u00eda a napi_gro_receive() que puede liberarlo; despu\u00e9s de llamarlo, desreferenciar skb puede desencadenar un use after free."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48961.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48961",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:07.887",
"lastModified": "2024-10-21T20:15:07.887",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mdio: fix unbalanced fwnode reference count in mdio_device_release()\n\nThere is warning report about of_node refcount leak\nwhile probing mdio device:\n\nOF: ERROR: memory leak, expected refcount 1 instead of 2,\nof_node_get()/of_node_put() unbalanced - destroy cset entry:\nattach overlay node /spi/soc@0/mdio@710700c0/ethernet@4\n\nIn of_mdiobus_register_device(), we increase fwnode refcount\nby fwnode_handle_get() before associating the of_node with\nmdio device, but it has never been decreased in normal path.\nSince that, in mdio_device_release(), it needs to call\nfwnode_handle_put() in addition instead of calling kfree()\ndirectly.\n\nAfter above, just calling mdio_device_free() in the error handle\npath of of_mdiobus_register_device() is enough to keep the\nrefcount balanced."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mdio: arregla el recuento de referencias de fwnode no balanceado en mdio_device_release() Hay un informe de advertencia sobre una fuga de recuento de referencias de of_node mientras se sondea el dispositivo mdio: OF: ERROR: fuga de memoria, se esperaba un recuento de referencias de 1 en lugar de 2, of_node_get()/of_node_put() no balanceado - destruye la entrada de cset: adjunta el nodo superpuesto /spi/soc@0/mdio@710700c0/ethernet@4 En of_mdiobus_register_device(), aumentamos el recuento de referencias de fwnode mediante fwnode_handle_get() antes de asociar el of_node con el dispositivo mdio, pero nunca se ha reducido en la ruta normal. Desde entonces, en mdio_device_release(), necesita llamar a fwnode_handle_put() adem\u00e1s en lugar de llamar a kfree() directamente. Despu\u00e9s de lo anterior, simplemente llamar a mdio_device_free() en la ruta del controlador de errores de of_mdiobus_register_device() es suficiente para mantener el recuento de referencias equilibrado."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48962.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48962",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:08.117",
"lastModified": "2024-10-21T20:15:08.117",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hisilicon: Fix potential use-after-free in hisi_femac_rx()\n\nThe skb is delivered to napi_gro_receive() which may free it, after\ncalling this, dereferencing skb may trigger use-after-free."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hisilicon: Se corrige un posible use after free en hisi_femac_rx() El skb se env\u00eda a napi_gro_receive() que puede liberarlo; despu\u00e9s de llamarlo, desreferenciar skb puede desencadenar un use after free."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48963.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48963",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:08.273",
"lastModified": "2024-10-21T20:15:08.273",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"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_mux_init()\n\nWhen failed to alloc ipc_mux->ul_adb.pp_qlt in ipc_mux_init(), ipc_mux\nis not released."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wwan: iosm: corrige p\u00e9rdida de memoria en ipc_mux_init() Cuando no se puede asignar ipc_mux-&gt;ul_adb.pp_qlt en ipc_mux_init(), ipc_mux no se libera."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48964.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48964",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:08.377",
"lastModified": "2024-10-21T20:15:08.377",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nravb: Fix potential use-after-free in ravb_rx_gbeth()\n\nThe skb is delivered to napi_gro_receive() which may free it, after calling this,\ndereferencing skb may trigger use-after-free."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ravb: Se corrige el posible use after free en ravb_rx_gbeth() El skb se entrega a napi_gro_receive() que puede liberarlo; despu\u00e9s de llamarlo, desreferenciar skb puede desencadenar el use after free."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48965.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48965",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:08.470",
"lastModified": "2024-10-21T20:15:08.470",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio/rockchip: fix refcount leak in rockchip_gpiolib_register()\n\nThe node returned by of_get_parent() with refcount incremented,\nof_node_put() needs be called when finish using it. So add it in the\nend of of_pinctrl_get()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio/rockchip: se corrige la p\u00e9rdida de recuento de referencias en rockchip_gpiolib_register(). El nodo devuelto por of_get_parent() con el recuento de referencias incrementado, se debe llamar a of_node_put() cuando se termina de usarlo. Por lo tanto, agr\u00e9guelo al final de of_pinctrl_get()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48966.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48966",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:08.573",
"lastModified": "2024-10-21T20:15:08.573",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mvneta: Prevent out of bounds read in mvneta_config_rss()\n\nThe pp->indir[0] value comes from the user. It is passed to:\n\n\tif (cpu_online(pp->rxq_def))\n\ninside the mvneta_percpu_elect() function. It needs bounds checkeding\nto ensure that it is not beyond the end of the cpu bitmap."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mvneta: Impedir lectura fuera de los l\u00edmites en mvneta_config_rss() El valor pp-&gt;indir[0] proviene del usuario. Se pasa a: if (cpu_online(pp-&gt;rxq_def)) dentro de la funci\u00f3n mvneta_percpu_elect(). Necesita una comprobaci\u00f3n de los l\u00edmites para garantizar que no est\u00e9 m\u00e1s all\u00e1 del final del mapa de bits de la CPU."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48967.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48967",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:08.757",
"lastModified": "2024-10-21T20:15:08.757",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFC: nci: Bounds check struct nfc_target arrays\n\nWhile running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:\n\n memcpy: detected field-spanning write (size 129) of single field \"target->sensf_res\" at net/nfc/nci/ntf.c:260 (size 18)\n\nThis appears to be a legitimate lack of bounds checking in\nnci_add_new_protocol(). Add the missing checks."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFC: nci: Comprobaci\u00f3n de los l\u00edmites de matrices struct nfc_target Mientras se ejecutaba bajo CONFIG_FORTIFY_SOURCE=y, syzkaller inform\u00f3: memcpy: se detect\u00f3 una escritura que abarcaba campos (tama\u00f1o 129) de un solo campo \"target-&gt;sensf_res\" en net/nfc/nci/ntf.c:260 (tama\u00f1o 18) Esto parece ser una falta leg\u00edtima de comprobaci\u00f3n de los l\u00edmites en nci_add_new_protocol(). Agregue las comprobaciones faltantes."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48968.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48968",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:08.897",
"lastModified": "2024-10-21T20:15:08.897",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: Fix potential memory leak in otx2_init_tc()\n\nIn otx2_init_tc(), if rhashtable_init() failed, it does not free\ntc->tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: corrige una posible p\u00e9rdida de memoria en otx2_init_tc(). En otx2_init_tc(), si rhashtable_init() fallo, no libera tc-&gt;tc_entries_bitmap que est\u00e1 asignado en otx2_tc_alloc_ent_bitmap()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48969.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48969",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.037",
"lastModified": "2024-10-21T20:15:09.037",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen-netfront: Fix NULL sring after live migration\n\nA NAPI is setup for each network sring to poll data to kernel\nThe sring with source host is destroyed before live migration and\nnew sring with target host is setup after live migration.\nThe NAPI for the old sring is not deleted until setup new sring\nwith target host after migration. With busy_poll/busy_read enabled,\nthe NAPI can be polled before got deleted when resume VM.\n\nBUG: unable to handle kernel NULL pointer dereference at\n0000000000000008\nIP: xennet_poll+0xae/0xd20\nPGD 0 P4D 0\nOops: 0000 [#1] SMP PTI\nCall Trace:\n finish_task_switch+0x71/0x230\n timerqueue_del+0x1d/0x40\n hrtimer_try_to_cancel+0xb5/0x110\n xennet_alloc_rx_buffers+0x2a0/0x2a0\n napi_busy_loop+0xdb/0x270\n sock_poll+0x87/0x90\n do_sys_poll+0x26f/0x580\n tracing_map_insert+0x1d4/0x2f0\n event_hist_trigger+0x14a/0x260\n\n finish_task_switch+0x71/0x230\n __schedule+0x256/0x890\n recalc_sigpending+0x1b/0x50\n xen_sched_clock+0x15/0x20\n __rb_reserve_next+0x12d/0x140\n ring_buffer_lock_reserve+0x123/0x3d0\n event_triggers_call+0x87/0xb0\n trace_event_buffer_commit+0x1c4/0x210\n xen_clocksource_get_cycles+0x15/0x20\n ktime_get_ts64+0x51/0xf0\n SyS_ppoll+0x160/0x1a0\n SyS_ppoll+0x160/0x1a0\n do_syscall_64+0x73/0x130\n entry_SYSCALL_64_after_hwframe+0x41/0xa6\n...\nRIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900\nCR2: 0000000000000008\n---[ end trace f8601785b354351c ]---\n\nxen frontend should remove the NAPIs for the old srings before live\nmigration as the bond srings are destroyed\n\nThere is a tiny window between the srings are set to NULL and\nthe NAPIs are disabled, It is safe as the NAPI threads are still\nfrozen at that time"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen-netfront: Reparar sring NULL despu\u00e9s de la migraci\u00f3n en vivo Se configura un NAPI para cada sring de red para sondear los datos al kernel El sring con el host de origen se destruye antes de la migraci\u00f3n en vivo y se configura el nuevo sring con el host de destino despu\u00e9s de la migraci\u00f3n en vivo. El NAPI para el sring antiguo no se elimina hasta que se configura el nuevo sring con el host de destino despu\u00e9s de la migraci\u00f3n. Con busy_poll/busy_read habilitado, el NAPI se puede sondear antes de que se elimine cuando se reanuda la VM. ERROR: no se puede manejar la desreferencia del puntero NULL del n\u00facleo en 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] Seguimiento de llamadas PTI de SMP: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 evento_hist_trigger+0x14a/0x260 finalizar_cambio_tarea+0x71/0x230 __schedule+0x256/0x890 recalc_sigping+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 reserva_bloqueo_buffer_anillo+0x123/0x3d0 llamada_activadores_evento+0x87/0xb0 confirmaci\u00f3n_buffer_evento_trace+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ fin del seguimiento f8601785b354351c ]--- la interfaz de xen debe eliminar las NAPI de los antiguos srings antes de la migraci\u00f3n en vivo, ya que los srings de enlace se destruyen. Hay una peque\u00f1a ventana entre los srings que se establecen en NULL y los NAPI que se deshabilitan. Es seguro ya que los subprocesos NAPI todav\u00eda est\u00e1n congelados en ese momento."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48970.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48970",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.177",
"lastModified": "2024-10-21T20:15:09.177",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Get user_ns from in_skb in unix_diag_get_exact().\n\nWei Chen reported a NULL deref in sk_user_ns() [0][1], and Paolo diagnosed\nthe root cause: in unix_diag_get_exact(), the newly allocated skb does not\nhave sk. [2]\n\nWe must get the user_ns from the NETLINK_CB(in_skb).sk and pass it to\nsk_diag_fill().\n\n[0]:\nBUG: kernel NULL pointer dereference, address: 0000000000000270\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0\nOops: 0000 [#1] PREEMPT SMP\nCPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014\nRIP: 0010:sk_user_ns include/net/sock.h:920 [inline]\nRIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [inline]\nRIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170\nCode: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8\n54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b\n9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d\nRSP: 0018:ffffc90000d67968 EFLAGS: 00010246\nRAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481d\nRDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270\nRBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000\nR10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800\nR13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940\nFS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n unix_diag_get_exact net/unix/diag.c:285 [inline]\n unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317\n __sock_diag_cmd net/core/sock_diag.c:235 [inline]\n sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266\n netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564\n sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277\n netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]\n netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356\n netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg net/socket.c:734 [inline]\n ____sys_sendmsg+0x38f/0x500 net/socket.c:2476\n ___sys_sendmsg net/socket.c:2530 [inline]\n __sys_sendmsg+0x197/0x230 net/socket.c:2559\n __do_sys_sendmsg net/socket.c:2568 [inline]\n __se_sys_sendmsg net/socket.c:2566 [inline]\n __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x4697f9\nCode: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48\n89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d\n01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9\nRDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003\nRBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80\nR13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0\n </TASK>\nModules linked in:\nCR2: 0000000000000270\n\n[1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/\n[2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Obtener user_ns de in_skb en unix_diag_get_exact(). Wei Chen inform\u00f3 una desreferencia NULL en sk_user_ns() [0][1], y Paolo diagnostic\u00f3 la causa ra\u00edz: en unix_diag_get_exact(), el skb reci\u00e9n asignado no tiene sk. [2] Debemos obtener el user_ns de NETLINK_CB(in_skb).sk y pasarlo a sk_diag_fill(). [0]: ERROR: desreferencia de puntero NULL del n\u00facleo, direcci\u00f3n: 0000000000000270 #PF: acceso de lectura del supervisor en modo n\u00facleo #PF: error_code(0x0000) - p\u00e1gina no presente PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 27942 Comm: syz-executor.0 No contaminado 6.1.0-rc5-next-20221118 #2 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:sk_user_ns include/net/sock.h:920 [en l\u00ednea] RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [en l\u00ednea] RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170 C\u00f3digo: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8 54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd &lt;48&gt; 8b 9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d RSP: 0018:ffffc90000d67968 EFLAGS: 00010246 RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ff840d481d RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270 RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000 R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800 R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940 FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: unix_diag_get_exact net/unix/diag.c:285 [en l\u00ednea] unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317 __sock_diag_cmd net/core/sock_diag.c:235 [en l\u00ednea] sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266 netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1330 [en l\u00ednea] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932 sock_sendmsg_nosec net/socket.c:714 [en l\u00ednea] sock_sendmsg net/socket.c:734 [en l\u00ednea] ____sys_sendmsg+0x38f/0x500 net/socket.c:2476 ___sys_sendmsg net/socket.c:2530 [en l\u00ednea] __sys_sendmsg+0x197/0x230 net/socket.c:2559 __do_sys_sendmsg net/socket.c:2568 [en l\u00ednea] __se_sys_sendmsg net/socket.c:2566 [en l\u00ednea] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4697f9 C\u00f3digo: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9 RDX: 000000000000000 RSI: 00000000200001c0 RDI: 000000000000003 RBP: 00000000004d29e9 R08: 0000000000000000 R09: 000000000000000 R10: 00000000000000000 R11: 0000000000000246 R12: 000000000077bf80 R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0 M\u00f3dulos vinculados en: CR2: 0000000000000270 [1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/ [2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48971.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48971",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.260",
"lastModified": "2024-10-21T20:15:09.260",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix not cleanup led when bt_init fails\n\nbt_init() calls bt_leds_init() to register led, but if it fails later,\nbt_leds_cleanup() is not called to unregister it.\n\nThis can cause panic if the argument \"bluetooth-power\" in text is freed\nand then another led_trigger_register() tries to access it:\n\nBUG: unable to handle page fault for address: ffffffffc06d3bc0\nRIP: 0010:strcmp+0xc/0x30\n Call Trace:\n <TASK>\n led_trigger_register+0x10d/0x4f0\n led_trigger_register_simple+0x7d/0x100\n bt_init+0x39/0xf7 [bluetooth]\n do_one_initcall+0xd0/0x4e0"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se solucion\u00f3 el problema de no limpiar el led cuando bt_init fallo bt_init() llama a bt_leds_init() para registrar el led, pero si falla m\u00e1s tarde, no se llama a bt_leds_cleanup() para anular su registro. Esto puede causar p\u00e1nico si se libera el argumento \"bluetooth-power\" en el texto y luego otro led_trigger_register() intenta acceder a \u00e9l: ERROR: no se puede manejar el error de p\u00e1gina para la direcci\u00f3n: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Seguimiento de llamadas: led_trigger_register+0x10d/0x4f0 led_trigger_register_simple+0x7d/0x100 bt_init+0x39/0xf7 [bluetooth] do_one_initcall+0xd0/0x4e0"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48972.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48972",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.343",
"lastModified": "2024-10-21T20:15:09.343",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()\n\nKernel fault injection test reports null-ptr-deref as follows:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nRIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114\nCall Trace:\n <TASK>\n raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87\n call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944\n unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982\n unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879\n register_netdevice+0x9a8/0xb90 net/core/dev.c:10083\n ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659\n ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229\n mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316\n\nieee802154_if_add() allocates wpan_dev as netdev's private data, but not\ninit the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage\nthe list when device register/unregister, and may lead to null-ptr-deref.\n\nUse INIT_LIST_HEAD() on it to initialize it correctly."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac802154: se corrige el INIT_LIST_HEAD faltante en ieee802154_if_add(). La prueba de inyecci\u00f3n de errores del kernel informa null-ptr-deref de la siguiente manera: ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Seguimiento de llamadas: raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316 ieee802154_if_add() asigna wpan_dev como datos privados de netdev, pero No inicializa la lista en la estructura wpan_dev. cfg802154_netdev_notifier_call() administra la lista cuando se registra o cancela el registro del dispositivo y puede generar una desreferencia de PTR nula. Use INIT_LIST_HEAD() para inicializarla correctamente."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48973.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48973",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.430",
"lastModified": "2024-10-21T20:15:09.430",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: amd8111: Fix PCI device reference count leak\n\nfor_each_pci_dev() is implemented by pci_get_device(). The comment of\npci_get_device() says that it will increase the reference count for the\nreturned pci_dev and also decrease the reference count for the input\npci_dev @from if it is not NULL.\n\nIf we break for_each_pci_dev() loop with pdev not NULL, we need to call\npci_dev_put() to decrease the reference count. Add the missing\npci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL\ninput parameter, there is no problem for the 'Device not found' branch.\nFor the normal path, add pci_dev_put() in amd_gpio_exit()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: amd8111: Se solucion\u00f3 la fuga de recuento de referencia del dispositivo PCI. for_each_pci_dev() se implementa mediante pci_get_device(). El comentario de pci_get_device() dice que aumentar\u00e1 el recuento de referencia para el pci_dev devuelto y tambi\u00e9n disminuir\u00e1 el recuento de referencia para el pci_dev de entrada @from si no es NULL. Si interrumpimos el bucle for_each_pci_dev() con pdev no NULL, debemos llamar a pci_dev_put() para disminuir el recuento de referencia. Agregue el pci_dev_put() faltante despu\u00e9s de la etiqueta 'out'. Dado que pci_dev_put() puede manejar el par\u00e1metro de entrada NULL, no hay ning\u00fan problema para la rama 'Dispositivo no encontrado'. Para la ruta normal, agregue pci_dev_put() en amd_gpio_exit()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48974.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48974",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.517",
"lastModified": "2024-10-21T20:15:09.517",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: fix using __this_cpu_add in preemptible\n\nCurrently in nf_conntrack_hash_check_insert(), when it fails in\nnf_ct_ext_valid_pre/post(), NF_CT_STAT_INC() will be called in the\npreemptible context, a call trace can be triggered:\n\n BUG: using __this_cpu_add() in preemptible [00000000] code: conntrack/1636\n caller is nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack]\n Call Trace:\n <TASK>\n dump_stack_lvl+0x33/0x46\n check_preemption_disabled+0xc3/0xf0\n nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack]\n ctnetlink_create_conntrack+0x3cd/0x4e0 [nf_conntrack_netlink]\n ctnetlink_new_conntrack+0x1c0/0x450 [nf_conntrack_netlink]\n nfnetlink_rcv_msg+0x277/0x2f0 [nfnetlink]\n netlink_rcv_skb+0x50/0x100\n nfnetlink_rcv+0x65/0x144 [nfnetlink]\n netlink_unicast+0x1ae/0x290\n netlink_sendmsg+0x257/0x4f0\n sock_sendmsg+0x5f/0x70\n\nThis patch is to fix it by changing to use NF_CT_STAT_INC_ATOMIC() for\nnf_ct_ext_valid_pre/post() check in nf_conntrack_hash_check_insert(),\nas well as nf_ct_ext_valid_post() in __nf_conntrack_confirm().\n\nNote that nf_ct_ext_valid_pre() check in __nf_conntrack_confirm() is\nsafe to use NF_CT_STAT_INC(), as it's under local_bh_disable()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: conntrack: correcci\u00f3n al usar __this_cpu_add en preemptible Actualmente en nf_conntrack_hash_check_insert(), cuando fallo en nf_ct_ext_valid_pre/post(), se llamar\u00e1 a NF_CT_STAT_INC() en el contexto preemptible, se puede activar un seguimiento de llamada: ERROR: uso de __this_cpu_add() en preemptible [00000000] c\u00f3digo: conntrack/1636 el llamador es nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack] Seguimiento de llamada: dump_stack_lvl+0x33/0x46 check_preemption_disabled+0xc3/0xf0 Este parche es para solucionarlo cambiando para usar NF_CT_STAT_INC_ATOMIC() para la comprobaci\u00f3n de nf_ct_ext_valid_pre/post() en nf_conntrack_hash_check_insert(), as\u00ed como nf_ct_ext_valid_post() en __nf_conntrack_confirm(). Tenga en cuenta que la comprobaci\u00f3n de nf_ct_ext_valid_pre() en __nf_conntrack_confirm() es segura para usar NF_CT_STAT_INC(), ya que se encuentra bajo local_bh_disable()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48975.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48975",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.597",
"lastModified": "2024-10-21T20:15:09.597",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpiolib: fix memory leak in gpiochip_setup_dev()\n\nHere is a backtrace report about memory leak detected in\ngpiochip_setup_dev():\n\nunreferenced object 0xffff88810b406400 (size 512):\n comm \"python3\", pid 1682, jiffies 4295346908 (age 24.090s)\n backtrace:\n kmalloc_trace\n device_add\t\tdevice_private_init at drivers/base/core.c:3361\n\t\t\t(inlined by) device_add at drivers/base/core.c:3411\n cdev_device_add\n gpiolib_cdev_register\n gpiochip_setup_dev\n gpiochip_add_data_with_key\n\ngcdev_register() & gcdev_unregister() would call device_add() &\ndevice_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to\nregister/unregister device.\n\nHowever, if device_add() succeeds, some resource (like\nstruct device_private allocated by device_private_init())\nis not released by device_del().\n\nTherefore, after device_add() succeeds by gcdev_register(), it\nneeds to call put_device() to release resource in the error handle\npath.\n\nHere we move forward the register of release function, and let it\nrelease every piece of resource by put_device() instead of kfree().\n\nWhile at it, fix another subtle issue, i.e. when gc->ngpio is equal\nto 0, we still call kcalloc() and, in case of further error, kfree()\non the ZERO_PTR pointer, which is not NULL. It's not a bug per se,\nbut rather waste of the resources and potentially wrong expectation\nabout contents of the gdev->descs variable."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: reparar p\u00e9rdida de memoria en gpiochip_setup_dev() Aqu\u00ed hay un informe de seguimiento sobre la p\u00e9rdida de memoria detectada en gpiochip_setup_dev(): objeto sin referencia 0xffff88810b406400 (tama\u00f1o 512): comm \"python3\", pid 1682, jiffies 4295346908 (edad 24.090s) seguimiento: kmalloc_trace device_add device_private_init en drivers/base/core.c:3361 (en l\u00ednea por) device_add en drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() y gcdev_unregister() llamar\u00edan device_add() y device_del() (sin importar si CONFIG_GPIO_CDEV est\u00e1 habilitado o no) para registrar/anular el registro del dispositivo. Sin embargo, si device_add() tiene \u00e9xito, alg\u00fan recurso (como la estructura device_private asignada por device_private_init()) no es liberado por device_del(). Por lo tanto, despu\u00e9s de que device_add() tenga \u00e9xito por gcdev_register(), necesita llamar a put_device() para liberar el recurso en la ruta del controlador de error. Aqu\u00ed avanzamos el registro de la funci\u00f3n de liberaci\u00f3n y dejamos que libere cada pieza de recurso por put_device() en lugar de kfree(). Mientras lo hacemos, solucionamos otro problema sutil, es decir, cuando gc-&gt;ngpio es igual a 0, todav\u00eda llamamos a kcalloc() y, en caso de un error adicional, a kfree() en el puntero ZERO_PTR, que no es NULL. No es un error en s\u00ed, sino m\u00e1s bien un desperdicio de recursos y una expectativa potencialmente err\u00f3nea sobre el contenido de la variable gdev-&gt;descs."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48976.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48976",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.680",
"lastModified": "2024-10-21T20:15:09.680",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable_offload: fix using __this_cpu_add in preemptible\n\nflow_offload_queue_work() can be called in workqueue without\nbh disabled, like the call trace showed in my act_ct testing,\ncalling NF_FLOW_TABLE_STAT_INC() there would cause a call\ntrace:\n\n BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u4:0/138560\n caller is flow_offload_queue_work+0xec/0x1b0 [nf_flow_table]\n Workqueue: act_ct_workqueue tcf_ct_flow_table_cleanup_work [act_ct]\n Call Trace:\n <TASK>\n dump_stack_lvl+0x33/0x46\n check_preemption_disabled+0xc3/0xf0\n flow_offload_queue_work+0xec/0x1b0 [nf_flow_table]\n nf_flow_table_iterate+0x138/0x170 [nf_flow_table]\n nf_flow_table_free+0x140/0x1a0 [nf_flow_table]\n tcf_ct_flow_table_cleanup_work+0x2f/0x2b0 [act_ct]\n process_one_work+0x6a3/0x1030\n worker_thread+0x8a/0xdf0\n\nThis patch fixes it by using NF_FLOW_TABLE_STAT_INC_ATOMIC()\ninstead in flow_offload_queue_work().\n\nNote that for FLOW_CLS_REPLACE branch in flow_offload_queue_work(),\nit may not be called in preemptible path, but it's good to use\nNF_FLOW_TABLE_STAT_INC_ATOMIC() for all cases in\nflow_offload_queue_work()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable_offload: correcci\u00f3n al usar __this_cpu_add en preemptible flow_offload_queue_work() se puede llamar en workqueue sin bh deshabilitado, como el seguimiento de llamadas que mostr\u00f3 en mi prueba act_ct, llamar a NF_FLOW_TABLE_STAT_INC() all\u00ed causar\u00eda un seguimiento de llamadas: ERROR: usar __this_cpu_add() en preemptible [00000000] c\u00f3digo: kworker/u4:0/138560 el llamador es flow_offload_queue_work+0xec/0x1b0 [nf_flow_table] Workqueue: act_ct_workqueue tcf_ct_flow_table_cleanup_work [act_ct] Seguimiento de llamadas: dump_stack_lvl+0x33/0x46 check_preemption_disabled+0xc3/0xf0 Este parche lo corrige al usar NF_FLOW_TABLE_STAT_INC_ATOMIC() en lugar de flow_offload_queue_work(). Tenga en cuenta que para la rama FLOW_CLS_REPLACE en flow_offload_queue_work(), es posible que no se la llame en una ruta preemptible, pero es bueno usar NF_FLOW_TABLE_STAT_INC_ATOMIC() para todos los casos en flow_offload_queue_work()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48977.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48977",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.763",
"lastModified": "2024-10-21T20:15:09.763",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: af_can: fix NULL pointer dereference in can_rcv_filter\n\nAnalogue to commit 8aa59e355949 (\"can: af_can: fix NULL pointer\ndereference in can_rx_register()\") we need to check for a missing\ninitialization of ml_priv in the receive path of CAN frames.\n\nSince commit 4e096a18867a (\"net: introduce CAN specific pointer in the\nstruct net_device\") the check for dev->type to be ARPHRD_CAN is not\nsufficient anymore since bonding or tun netdevices claim to be CAN\ndevices but do not initialize ml_priv accordingly."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: af_can: fix NULL pointer dereference in can_rcv_filter De manera an\u00e1loga a el commit 8aa59e355949 (\"can: af_can: fix NULL pointer dereference in can_rx_register()\"), debemos comprobar si falta una inicializaci\u00f3n de ml_priv en la ruta de recepci\u00f3n de los marcos CAN. Desde el commit 4e096a18867a (\"net: introduce CAN specific pointer in the struct net_device\"), la comprobaci\u00f3n de que dev-&gt;type sea ARPHRD_CAN ya no es suficiente, ya que los netdevices bonding o tun afirman ser dispositivos CAN pero no inicializan ml_priv en consecuencia."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48978.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48978",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.850",
"lastModified": "2024-10-21T20:15:09.850",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: fix shift-out-of-bounds in hid_report_raw_event\n\nSyzbot reported shift-out-of-bounds in hid_report_raw_event.\n\nmicrosoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >\n32! (swapper/0)\n======================================================================\nUBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20\nshift exponent 127 is too large for 32-bit type 'int'\nCPU: 0 PID: 0 Comm: swapper/0 Not tainted\n6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0\nHardware name: Google Compute Engine/Google Compute Engine, BIOS\nGoogle 10/26/2022\nCall Trace:\n <IRQ>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106\n ubsan_epilogue lib/ubsan.c:151 [inline]\n __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322\n snto32 drivers/hid/hid-core.c:1323 [inline]\n hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]\n hid_process_report drivers/hid/hid-core.c:1665 [inline]\n hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998\n hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066\n hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284\n __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671\n dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988\n call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474\n expire_timers kernel/time/timer.c:1519 [inline]\n __run_timers+0x76a/0x980 kernel/time/timer.c:1790\n run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803\n __do_softirq+0x277/0x75b kernel/softirq.c:571\n __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650\n irq_exit_rcu+0x5/0x20 kernel/softirq.c:662\n sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107\n======================================================================\n\nIf the size of the integer (unsigned n) is bigger than 32 in snto32(),\nshift exponent will be too large for 32-bit type 'int', resulting in a\nshift-out-of-bounds bug.\nFix this by adding a check on the size of the integer (unsigned n) in\nsnto32(). To add support for n greater than 32 bits, set n to 32, if n\nis greater than 32."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: n\u00facleo: se corrige un desplazamiento fuera de los l\u00edmites en hid_report_raw_event Syzbot inform\u00f3 un desplazamiento fuera de los l\u00edmites en hid_report_raw_event. microsoft 0003:045E:07DA.0001: hid_field_extract() llamado con n (128) &gt; 32! (swapper/0) ========================================================================== UBSAN: cambio fuera de los l\u00edmites en drivers/hid/hid-core.c:1323:20 el exponente de cambio 127 es demasiado grande para el tipo de 32 bits 'int' CPU: 0 PID: 0 Comm: swapper/0 No contaminado 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 Rastreo de llamadas: __dump_stack lib/dump_stack.c:88 [en l\u00ednea] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [en l\u00ednea] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [en l\u00ednea] hid_input_fetch_field drivers/hid/hid-core.c:1572 [en l\u00ednea] hid_process_report drivers/hid/hid-core.c:1665 [en l\u00ednea] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [en l\u00ednea] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ================================================================================== Si el tama\u00f1o del entero (n sin signo) es mayor que 32 en snto32(), el exponente de desplazamiento ser\u00e1 demasiado grande para 32 bits. Tipo 'int', lo que genera un error de desplazamiento fuera de los l\u00edmites. Solucione este problema agregando una verificaci\u00f3n del tama\u00f1o del entero (n sin signo) en snto32(). Para agregar compatibilidad con n mayor que 32 bits, configure n en 32, si n es mayor que 32."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48979.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48979",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:09.947",
"lastModified": "2024-10-21T20:15:09.947",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: fix array index out of bound error in DCN32 DML\n\n[Why&How]\nLinkCapacitySupport array is indexed with the number of voltage states and\nnot the number of max DPPs. Fix the error by changing the array\ndeclaration to use the correct (larger) array size of total number of\nvoltage states."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: se corrige el error de \u00edndice de matriz fuera de l\u00edmite en DCN32 DML [Por qu\u00e9 y c\u00f3mo] La matriz LinkCapacitySupport est\u00e1 indexada con la cantidad de estados de voltaje y no con la cantidad m\u00e1xima de DPP. Corrija el error modificando la declaraci\u00f3n de la matriz para utilizar el tama\u00f1o de matriz correcto (m\u00e1s grande) de la cantidad total de estados de voltaje."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48980.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48980",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.037",
"lastModified": "2024-10-21T20:15:10.037",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()\n\nThe SJA1105 family has 45 L2 policing table entries\n(SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110\n(SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but\naccounting for the difference in port count (5 in SJA1105 vs 10 in\nSJA1110) does not fully explain the difference. Rather, the SJA1110 also\nhas L2 ingress policers for multicast traffic. If a packet is classified\nas multicast, it will be processed by the policer index 99 + SRCPORT.\n\nThe sja1105_init_l2_policing() function initializes all L2 policers such\nthat they don't interfere with normal packet reception by default. To have\na common code between SJA1105 and SJA1110, the index of the multicast\npolicer for the port is calculated because it's an index that is out of\nbounds for SJA1105 but in bounds for SJA1110, and a bounds check is\nperformed.\n\nThe code fails to do the proper thing when determining what to do with the\nmulticast policer of port 0 on SJA1105 (ds->num_ports = 5). The \"mcast\"\nindex will be equal to 45, which is also equal to\ntable->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes\nthrough the check. But at the same time, SJA1105 doesn't have multicast\npolicers. So the code programs the SHARINDX field of an out-of-bounds\nelement in the L2 Policing table of the static config.\n\nThe comparison between index 45 and 45 entries should have determined the\ncode to not access this policer index on SJA1105, since its memory wasn't\neven allocated.\n\nWith enough bad luck, the out-of-bounds write could even overwrite other\nvalid kernel data, but in this case, the issue was detected using KASAN.\n\nKernel log:\n\nsja1105 spi5.0: Probed switch chip: SJA1105Q\n==================================================================\nBUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340\nWrite of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8\n...\nWorkqueue: events_unbound deferred_probe_work_func\nCall trace:\n...\nsja1105_setup+0x1cbc/0x2340\ndsa_register_switch+0x1284/0x18d0\nsja1105_probe+0x748/0x840\n...\nAllocated by task 8:\n...\nsja1105_setup+0x1bcc/0x2340\ndsa_register_switch+0x1284/0x18d0\nsja1105_probe+0x748/0x840\n..."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: sja1105: evitar acceso fuera de los l\u00edmites en sja1105_init_l2_policing() La familia SJA1105 tiene 45 entradas de tabla de control de L2 (SJA1105_MAX_L2_POLICING_COUNT) y SJA1110 tiene 110 (SJA1110_MAX_L2_POLICING_COUNT). Mantener la estructura de la tabla pero tener en cuenta la diferencia en el recuento de puertos (5 en SJA1105 frente a 10 en SJA1110) no explica completamente la diferencia. En cambio, SJA1110 tambi\u00e9n tiene controladores de ingreso de L2 para tr\u00e1fico de multidifusi\u00f3n. Si un paquete se clasifica como de multidifusi\u00f3n, ser\u00e1 procesado por el \u00edndice de controlador 99 + SRCPORT. La funci\u00f3n sja1105_init_l2_policing() inicializa todos los controladores de L2 de modo que no interfieran con la recepci\u00f3n normal de paquetes de forma predeterminada. Para tener un c\u00f3digo com\u00fan entre SJA1105 y SJA1110, se calcula el \u00edndice del controlador de multidifusi\u00f3n para el puerto porque es un \u00edndice que est\u00e1 fuera de los l\u00edmites para SJA1105 pero dentro de los l\u00edmites para SJA1110, y se realiza una comprobaci\u00f3n de los l\u00edmites. El c\u00f3digo no hace lo correcto al determinar qu\u00e9 hacer con el controlador de multidifusi\u00f3n del puerto 0 en SJA1105 (ds-&gt;num_ports = 5). El \u00edndice \"mcast\" ser\u00e1 igual a 45, que tambi\u00e9n es igual a table-&gt;ops-&gt;max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). Por lo tanto, pasa por la comprobaci\u00f3n. Pero al mismo tiempo, SJA1105 no tiene controladores de multidifusi\u00f3n. Por lo tanto, el c\u00f3digo programa el campo SHARINDX de un elemento fuera de los l\u00edmites en la tabla de control L2 de la configuraci\u00f3n est\u00e1tica. La comparaci\u00f3n entre las entradas del \u00edndice 45 y 45 deber\u00eda haber determinado que el c\u00f3digo no accediera a este \u00edndice de control en SJA1105, ya que su memoria ni siquiera estaba asignada. Con suficiente mala suerte, la escritura fuera de los l\u00edmites podr\u00eda incluso sobrescribir otros datos v\u00e1lidos del kernel, pero en este caso, el problema se detect\u00f3 mediante KASAN. Registro del n\u00facleo: sja1105 spi5.0: Chip conmutador sondeado: SJA1105Q ===================================================================== ERROR: KASAN: slab fuera de los l\u00edmites en sja1105_setup+0x1cbc/0x2340 Escritura de tama\u00f1o 8 en la direcci\u00f3n ffffff880bd57708 por la tarea kworker/u8:0/8 ... Cola de trabajo: events_unbound deferred_probe_work_func Rastreo de llamadas: ... sja1105_setup+0x1cbc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ... Asignado por la tarea 8: ... sja1105_setup+0x1bcc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ..."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48981.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48981",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.130",
"lastModified": "2024-10-21T20:15:10.130",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/shmem-helper: Remove errant put in error path\n\ndrm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM\nobject getting prematurely freed leading to a later use-after-free."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/shmem-helper: eliminar una ubicaci\u00f3n errada en la ruta de error drm_gem_shmem_mmap() no posee esta referencia, lo que provoca que el objeto GEM se libere prematuramente y lleve a un use after free."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48982.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48982",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.210",
"lastModified": "2024-10-21T20:15:10.210",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix crash when replugging CSR fake controllers\n\nIt seems fake CSR 5.0 clones can cause the suspend notifier to be\nregistered twice causing the following kernel panic:\n\n[ 71.986122] Call Trace:\n[ 71.986124] <TASK>\n[ 71.986125] blocking_notifier_chain_register+0x33/0x60\n[ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da]\n[ 71.986154] btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477]\n[ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300\n[ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90\n[ 71.986167] usb_probe_interface+0xe3/0x2b0\n[ 71.986171] really_probe+0xdb/0x380\n[ 71.986174] ? pm_runtime_barrier+0x54/0x90\n[ 71.986177] __driver_probe_device+0x78/0x170\n[ 71.986180] driver_probe_device+0x1f/0x90\n[ 71.986183] __device_attach_driver+0x89/0x110\n[ 71.986186] ? driver_allows_async_probing+0x70/0x70\n[ 71.986189] bus_for_each_drv+0x8c/0xe0\n[ 71.986192] __device_attach+0xb2/0x1e0\n[ 71.986195] bus_probe_device+0x92/0xb0\n[ 71.986198] device_add+0x422/0x9a0\n[ 71.986201] ? sysfs_merge_group+0xd4/0x110\n[ 71.986205] usb_set_configuration+0x57a/0x820\n[ 71.986208] usb_generic_driver_probe+0x4f/0x70\n[ 71.986211] usb_probe_device+0x3a/0x110\n[ 71.986213] really_probe+0xdb/0x380\n[ 71.986216] ? pm_runtime_barrier+0x54/0x90\n[ 71.986219] __driver_probe_device+0x78/0x170\n[ 71.986221] driver_probe_device+0x1f/0x90\n[ 71.986224] __device_attach_driver+0x89/0x110\n[ 71.986227] ? driver_allows_async_probing+0x70/0x70\n[ 71.986230] bus_for_each_drv+0x8c/0xe0\n[ 71.986232] __device_attach+0xb2/0x1e0\n[ 71.986235] bus_probe_device+0x92/0xb0\n[ 71.986237] device_add+0x422/0x9a0\n[ 71.986239] ? _dev_info+0x7d/0x98\n[ 71.986242] ? blake2s_update+0x4c/0xc0\n[ 71.986246] usb_new_device.cold+0x148/0x36d\n[ 71.986250] hub_event+0xa8a/0x1910\n[ 71.986255] process_one_work+0x1c4/0x380\n[ 71.986259] worker_thread+0x51/0x390\n[ 71.986262] ? rescuer_thread+0x3b0/0x3b0\n[ 71.986264] kthread+0xdb/0x110\n[ 71.986266] ? kthread_complete_and_exit+0x20/0x20\n[ 71.986268] ret_from_fork+0x1f/0x30\n[ 71.986273] </TASK>\n[ 71.986274] ---[ end trace 0000000000000000 ]---\n[ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se soluciona el fallo al volver a conectar controladores falsos de CSR Parece que los clones falsos de CSR 5.0 pueden provocar que el notificador de suspensi\u00f3n se registre dos veces, lo que provoca el siguiente p\u00e1nico del kernel: [ 71.986122] Seguimiento de llamadas: [ 71.986124] [ 71.986125] blocking_notifier_chain_register+0x33/0x60 [ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [ 71.986154] btusb_probe+0x979/0xd85 [btusb es: e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300 [ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90 [ 71.986167] interfaz_sonda_usb+0xe3/0x2b0 [ 71.986171] realmente_sonda+0xdb/0x380 [ 71.986174] ? pm_runtime_barrier+0x54/0x90 [ 71.986177] __driver_probe_device+0x78/0x170 [ 71.986180] __driver_probe_device+0x1f/0x90 [ 71.986183] __device_attach_driver+0x89/0x110 [ 71.986186] ? driver_allows_async_probing+0x70/0x70 [ 71.986189] bus_para_cada_unidad+0x8c/0xe0 [ 71.986192] __dispositivo_adjunto+0xb2/0x1e0 [ 71.986195] bus_sondeo_dispositivo+0x92/0xb0 [ 71.986198] dispositivo_agregado+0x422/0x9a0 [ 71.986201] ? usb_probe_device+0x3a/0x110 [ 71.986213] realmente_probe+0xdb/0x380 [ 71.986216] ? pm_runtime_barrier+0x54/0x90 [ 71.986219] __driver_probe_device+0x78/0x170 [ 71.986221] driver_probe_device+0x1f/0x90 [ 71.986224] __device_attach_driver+0x89/0x110 [ 71.986227] ? driver_allows_async_probing+0x70/0x70 [ 71.986230] bus_para_cada_unidad+0x8c/0xe0 [ 71.986232] __device_attach+0xb2/0x1e0 [ 71.986235] bus_probe_device+0x92/0xb0 [ 71.986237] device_add+0x422/0x9a0 [ 71.986239] ? _dev_info+0x7d/0x98 [ 71.986242] ? subproceso de rescate+0x3b0/0x3b0 [ 71.986264] kthread+0xdb/0x110 [ 71.986266] ? kthread_complete_and_exit+0x20/0x20 [ 71.986268] ret_from_fork+0x1f/0x30 [ 71.986273] [ 71.986274] ---[ fin de seguimiento 000000000000000 ]--- [ 71.986284] btusb: la sonda de 2-1.6:1.0 fall\u00f3 con el error -17"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48983.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48983",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.283",
"lastModified": "2024-10-21T20:15:10.283",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: Fix a null-ptr-deref in io_tctx_exit_cb()\n\nSyzkaller reports a NULL deref bug as follows:\n\n BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3\n Read of size 4 at addr 0000000000000138 by task file1/1955\n\n CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\n Call Trace:\n <TASK>\n dump_stack_lvl+0xcd/0x134\n ? io_tctx_exit_cb+0x53/0xd3\n kasan_report+0xbb/0x1f0\n ? io_tctx_exit_cb+0x53/0xd3\n kasan_check_range+0x140/0x190\n io_tctx_exit_cb+0x53/0xd3\n task_work_run+0x164/0x250\n ? task_work_cancel+0x30/0x30\n get_signal+0x1c3/0x2440\n ? lock_downgrade+0x6e0/0x6e0\n ? lock_downgrade+0x6e0/0x6e0\n ? exit_signals+0x8b0/0x8b0\n ? do_raw_read_unlock+0x3b/0x70\n ? do_raw_spin_unlock+0x50/0x230\n arch_do_signal_or_restart+0x82/0x2470\n ? kmem_cache_free+0x260/0x4b0\n ? putname+0xfe/0x140\n ? get_sigframe_size+0x10/0x10\n ? do_execveat_common.isra.0+0x226/0x710\n ? lockdep_hardirqs_on+0x79/0x100\n ? putname+0xfe/0x140\n ? do_execveat_common.isra.0+0x238/0x710\n exit_to_user_mode_prepare+0x15f/0x250\n syscall_exit_to_user_mode+0x19/0x50\n do_syscall_64+0x42/0xb0\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0023:0x0\n Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\n R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n </TASK>\n Kernel panic - not syncing: panic_on_warn set ...\n\nThis happens because the adding of task_work from io_ring_exit_work()\nisn't synchronized with canceling all work items from eg exec. The\nexecution of the two are ordered in that they are both run by the task\nitself, but if io_tctx_exit_cb() is queued while we're canceling all\nwork items off exec AND gets executed when the task exits to userspace\nrather than in the main loop in io_uring_cancel_generic(), then we can\nfind current->io_uring == NULL and hit the above crash.\n\nIt's safe to add this NULL check here, because the execution of the two\npaths are done by the task itself.\n\n[axboe: add code comment and also put an explanation in the commit msg]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: Se corrige un null-ptr-deref en io_tctx_exit_cb() Syzkaller informa un error de desreferencia NULL de la siguiente manera: ERROR: KASAN: null-ptr-deref en io_tctx_exit_cb+0x53/0xd3 Lectura de tama\u00f1o 4 en la direcci\u00f3n 0000000000000138 por la tarea file1/1955 CPU: 1 PID: 1955 Comm: file1 No contaminado 6.1.0-rc7-00103-gef4d3ea40565 #75 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Seguimiento de llamadas: nivel_pila_volcado+0xcd/0x134 ? io_tctx_salir_cb+0x53/0xd3 informe_kasan+0xbb/0x1f0 ? io_tctx_salir_cb+0x53/0xd3 rango_comprobaci\u00f3n_kasan+0x140/0x190 io_tctx_salir_cb+0x53/0xd3 ejecuci\u00f3n_trabajo_tarea+0x164/0x250 ? cancelaci\u00f3n_trabajo_tarea+0x30/0x30 obtener_se\u00f1al+0x1c3/0x2440 ? degradaci\u00f3n_bloqueo+0x6e0/0x6e0 ? degradaci\u00f3n_bloqueo+0x6e0/0x6e0 ? se\u00f1ales_salida+0x8b0/0x8b0 ? desbloqueo_lectura_sin_datos+0x3b/0x70 ? obtener_sigframe_size+0x10/0x10 ? bloquear_hardirqs_on+0x79/0x100 ? poner_nombre+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_prepare+0x15f/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0023:0x0 C\u00f3digo: No se puede acceder a los bytes del c\u00f3digo de operaci\u00f3n en 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000 RDI: 000000000000000 RBP: 000000000000000 R08: 0000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 P\u00e1nico del kernel: no se sincroniza: panic_on_warn establecido ... Esto sucede porque la adici\u00f3n de task_work desde io_ring_exit_work() no est\u00e1 sincronizada con la cancelaci\u00f3n de todos los elementos de trabajo, por ejemplo, de exec. La ejecuci\u00f3n de los dos est\u00e1 ordenada de manera que ambos son ejecutados por la propia tarea, pero si io_tctx_exit_cb() est\u00e1 en cola mientras cancelamos todos los elementos de trabajo de exec Y se ejecuta cuando la tarea sale al espacio de usuario en lugar de en el bucle principal en io_uring_cancel_generic(), entonces podemos encontrar current-&gt;io_uring == NULL y alcanzar el bloqueo anterior. Es seguro agregar esta verificaci\u00f3n NULL aqu\u00ed, porque la ejecuci\u00f3n de las dos rutas las realiza la propia tarea. [axboe: agregue un comentario de c\u00f3digo y tambi\u00e9n coloque una explicaci\u00f3n en el mensaje de confirmaci\u00f3n]"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48984.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48984",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.360",
"lastModified": "2024-10-21T20:15:10.360",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: slcan: fix freed work crash\n\nThe LTP test pty03 is causing a crash in slcan:\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014\n Workqueue: 0x0 (events)\n RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185)\n Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e\n RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046\n RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968\n RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0\n RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734\n R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000\n R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0\n FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0\n Call Trace:\n <TASK>\n worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436)\n kthread (/home/rich/kernel/linux/kernel/kthread.c:376)\n ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312)\n\nApparently, the slcan's tx_work is freed while being scheduled. While\nslcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work),\nslcan_close() (tty side) does not. So when the netdev is never set UP,\nbut the tty is stuffed with bytes and forced to wakeup write, the work\nis scheduled, but never flushed.\n\nSo add an additional flush_work() to slcan_close() to be sure the work\nis flushed under all circumstances.\n\nThe Fixes commit below moved flush_work() from slcan_close() to\nslcan_netdev_close(). What was the rationale behind it? Maybe we can\ndrop the one in slcan_netdev_close()?\n\nI see the same pattern in can327. So it perhaps needs the very same fix."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: slcan: fix freed work crash La prueba LTP pty03 est\u00e1 provocando un fallo en slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 01/04/2014 Cola de trabajo: 0x0 (eventos) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) C\u00f3digo: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 &lt;49&gt; 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Seguimiento de llamadas: worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) Aparentemente, el tx_work de slcan se libera mientras se programa. Mientras que slcan_netdev_close() (lado netdev) llama a flush_work(&amp;sl-&gt;tx_work), slcan_close() (lado tty) no lo hace. Entonces, cuando el netdev nunca se configura, pero el tty est\u00e1 lleno de bytes y se lo obliga a activar la escritura, el trabajo se programa, pero nunca se vac\u00eda. Por lo tanto, agregue un flush_work() adicional a slcan_close() para asegurarse de que el trabajo se vac\u00eda en todas las circunstancias. el commit de correcciones a continuaci\u00f3n movi\u00f3 flush_work() de slcan_close() a slcan_netdev_close(). \u00bfCu\u00e1l fue la raz\u00f3n detr\u00e1s de esto? \u00bfQuiz\u00e1s podamos eliminar el que est\u00e1 en slcan_netdev_close()? Veo el mismo patr\u00f3n en can327. Entonces, tal vez necesite la misma correcci\u00f3n."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48985.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48985",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.463",
"lastModified": "2024-10-21T20:15:10.463",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mana: Fix race on per-CQ variable napi work_done\n\nAfter calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be\ncleared, and another CPU can start napi thread and access per-CQ variable,\ncq->work_done. If the other thread (for example, from busy_poll) sets\nit to a value >= budget, this thread will continue to run when it should\nstop, and cause memory corruption and panic.\n\nTo fix this issue, save the per-CQ work_done variable in a local variable\nbefore napi_complete_done(), so it won't be corrupted by a possible\nconcurrent thread after napi_complete_done().\n\nAlso, add a flag bit to advertise to the NIC firmware: the NAPI work_done\nvariable race is fixed, so the driver is able to reliably support features\nlike busy_poll."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: Corregir ejecuci\u00f3n en la variable per-CQ napi work_done Despu\u00e9s de llamar a napi_complete_done(), el bit NAPIF_STATE_SCHED puede borrarse, y otra CPU puede iniciar el hilo napi y acceder a la variable per-CQ, cq-&gt;work_done. Si el otro hilo (por ejemplo, desde busy_poll) lo establece en un valor &gt;= budget, este hilo seguir\u00e1 ejecut\u00e1ndose cuando deber\u00eda detenerse, y provocar\u00e1 corrupci\u00f3n de memoria y p\u00e1nico. Para solucionar este problema, guarde la variable per-CQ work_done en una variable local antes de napi_complete_done(), para que no se corrompa por un posible hilo concurrente despu\u00e9s de napi_complete_done(). Adem\u00e1s, agregue un bit de bandera para anunciar al firmware NIC: la ejecuci\u00f3n de la variable NAPI work_done est\u00e1 fija, por lo que el controlador puede soportar de forma fiable funciones como busy_poll."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48986.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48986",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.527",
"lastModified": "2024-10-21T20:15:10.527",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/gup: fix gup_pud_range() for dax\n\nFor dax pud, pud_huge() returns true on x86. So the function works as long\nas hugetlb is configured. However, dax doesn't depend on hugetlb.\nCommit 414fd080d125 (\"mm/gup: fix gup_pmd_range() for dax\") fixed\ndevmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as\nwell.\n\nThis fixes the below kernel panic:\n\ngeneral protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP\n\t< snip >\nCall Trace:\n<TASK>\nget_user_pages_fast+0x1f/0x40\niov_iter_get_pages+0xc6/0x3b0\n? mempool_alloc+0x5d/0x170\nbio_iov_iter_get_pages+0x82/0x4e0\n? bvec_alloc+0x91/0xc0\n? bio_alloc_bioset+0x19a/0x2a0\nblkdev_direct_IO+0x282/0x480\n? __io_complete_rw_common+0xc0/0xc0\n? filemap_range_has_page+0x82/0xc0\ngeneric_file_direct_write+0x9d/0x1a0\n? inode_update_time+0x24/0x30\n__generic_file_write_iter+0xbd/0x1e0\nblkdev_write_iter+0xb4/0x150\n? io_import_iovec+0x8d/0x340\nio_write+0xf9/0x300\nio_issue_sqe+0x3c3/0x1d30\n? sysvec_reschedule_ipi+0x6c/0x80\n__io_queue_sqe+0x33/0x240\n? fget+0x76/0xa0\nio_submit_sqes+0xe6a/0x18d0\n? __fget_light+0xd1/0x100\n__x64_sys_io_uring_enter+0x199/0x880\n? __context_tracking_enter+0x1f/0x70\n? irqentry_exit_to_user_mode+0x24/0x30\n? irqentry_exit+0x1d/0x30\n? __context_tracking_exit+0xe/0x70\ndo_syscall_64+0x3b/0x90\nentry_SYSCALL_64_after_hwframe+0x61/0xcb\nRIP: 0033:0x7fc97c11a7be\n\t< snip >\n</TASK>\n---[ end trace 48b2e0e67debcaeb ]---\nRIP: 0010:internal_get_user_pages_fast+0x340/0x990\n\t< snip >\nKernel panic - not syncing: Fatal exception\nKernel Offset: disabled"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: fix gup_pud_range() for dax Para dax pud, pud_huge() devuelve true en x86. Por lo tanto, la funci\u00f3n funciona siempre que hugetlb est\u00e9 configurado. Sin embargo, dax no depende de hugetlb. el commit 414fd080d125 (\"mm/gup: fix gup_pmd_range() for dax\") corrigi\u00f3 los PMD enormes respaldados por devmap, pero omiti\u00f3 los PUD enormes respaldados por devmap. Corrija esto tambi\u00e9n. Esto corrige el siguiente p\u00e1nico del kernel: error de protecci\u00f3n general, probablemente para la direcci\u00f3n no can\u00f3nica 0x69e7c000cc478: 0000 [#1] SMP &lt; snip &gt; Call Trace: get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? rango_mapa_archivo_tiene_p\u00e1gina+0x82/0xc0 escritura_directa_archivo_gen\u00e9rico+0x9d/0x1a0 ? tiempo_actualizaci\u00f3n_inodo+0x24/0x30 __iter_escritura_archivo_gen\u00e9rico+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100 __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be &lt; snip &gt; ---[ fin del seguimiento 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 &lt; snip &gt; P\u00e1nico del n\u00facleo: no se sincroniza: Excepci\u00f3n fatal Desplazamiento del n\u00facleo: deshabilitado"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48987.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48987",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.617",
"lastModified": "2024-10-21T20:15:10.617",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-dv-timings.c: fix too strict blanking sanity checks\n\nSanity checks were added to verify the v4l2_bt_timings blanking fields\nin order to avoid integer overflows when userspace passes weird values.\n\nBut that assumed that userspace would correctly fill in the front porch,\nbackporch and sync values, but sometimes all you know is the total\nblanking, which is then assigned to just one of these fields.\n\nAnd that can fail with these checks.\n\nSo instead set a maximum for the total horizontal and vertical\nblanking and check that each field remains below that.\n\nThat is still sufficient to avoid integer overflows, but it also\nallows for more flexibility in how userspace fills in these fields."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: v4l2-dv-timings.c: se corrigen comprobaciones de cordura de borrado demasiado estrictas Se a\u00f1adieron comprobaciones de cordura para verificar los campos de borrado de v4l2_bt_timings para evitar desbordamientos de enteros cuando el espacio de usuario pasa valores extra\u00f1os. Pero eso supon\u00eda que el espacio de usuario rellenar\u00eda correctamente los valores de front porch, back porch y sync, pero a veces todo lo que sabes es el borrado total, que luego se asigna a solo uno de estos campos. Y eso puede fallar con estas comprobaciones. As\u00ed que, en su lugar, establece un m\u00e1ximo para el borrado horizontal y vertical total y comprueba que cada campo permanezca por debajo de eso. Eso sigue siendo suficiente para evitar desbordamientos de enteros, pero tambi\u00e9n permite m\u00e1s flexibilidad en c\u00f3mo el espacio de usuario rellena estos campos."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48988.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48988",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.710",
"lastModified": "2024-10-21T20:15:10.710",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: fix possible use-after-free in memcg_write_event_control()\n\nmemcg_write_event_control() accesses the dentry->d_name of the specified\ncontrol fd to route the write call. As a cgroup interface file can't be\nrenamed, it's safe to access d_name as long as the specified file is a\nregular cgroup file. Also, as these cgroup interface files can't be\nremoved before the directory, it's safe to access the parent too.\n\nPrior to 347c4a874710 (\"memcg: remove cgroup_event->cft\"), there was a\ncall to __file_cft() which verified that the specified file is a regular\ncgroupfs file before further accesses. The cftype pointer returned from\n__file_cft() was no longer necessary and the commit inadvertently dropped\nthe file type check with it allowing any file to slip through. With the\ninvarients broken, the d_name and parent accesses can now race against\nrenames and removals of arbitrary files and cause use-after-free's.\n\nFix the bug by resurrecting the file type check in __file_cft(). Now that\ncgroupfs is implemented through kernfs, checking the file operations needs\nto go through a layer of indirection. Instead, let's check the superblock\nand dentry type."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memcg: corregir posible use after free en memcg_write_event_control() memcg_write_event_control() accede a dentry-&gt;d_name del fd de control especificado para enrutar la llamada de escritura. Como no se puede cambiar el nombre de un archivo de interfaz de cgroup, es seguro acceder a d_name siempre que el archivo especificado sea un archivo cgroup normal. Adem\u00e1s, como estos archivos de interfaz de cgroup no se pueden eliminar antes del directorio, tambi\u00e9n es seguro acceder al padre. Antes de 347c4a874710 (\"memcg: eliminar cgroup_event-&gt;cft\"), hab\u00eda una llamada a __file_cft() que verificaba que el archivo especificado es un archivo cgroupfs normal antes de futuros accesos. El puntero cftype devuelto desde __file_cft() ya no era necesario y el commit elimin\u00f3 inadvertidamente la verificaci\u00f3n del tipo de archivo, lo que permiti\u00f3 que cualquier archivo se deslizara. Con las invariantes rotas, los accesos a d_name y a los padres ahora pueden competir contra los cambios de nombre y las eliminaciones de archivos arbitrarios y causar use-after-free. Corrija el error resucitando la comprobaci\u00f3n del tipo de archivo en __file_cft(). Ahora que cgroupfs est\u00e1 implementado a trav\u00e9s de kernfs, la comprobaci\u00f3n de las operaciones de archivo debe pasar por una capa de indirecci\u00f3n. En su lugar, verifiquemos el tipo de superbloque y dentry."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48989.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48989",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.820",
"lastModified": "2024-10-21T20:15:10.820",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfscache: Fix oops due to race with cookie_lru and use_cookie\n\nIf a cookie expires from the LRU and the LRU_DISCARD flag is set, but\nthe state machine has not run yet, it's possible another thread can call\nfscache_use_cookie and begin to use it.\n\nWhen the cookie_worker finally runs, it will see the LRU_DISCARD flag\nset, transition the cookie->state to LRU_DISCARDING, which will then\nwithdraw the cookie. Once the cookie is withdrawn the object is removed\nthe below oops will occur because the object associated with the cookie\nis now NULL.\n\nFix the oops by clearing the LRU_DISCARD bit if another thread uses the\ncookie before the cookie_worker runs.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n ...\n CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x86_64 #1\n Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022\n Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs]\n RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles]\n ...\n Call Trace:\n netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs]\n process_one_work+0x217/0x3e0\n worker_thread+0x4a/0x3b0\n kthread+0xd6/0x100"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscache: Corregir oops debido a ejecuci\u00f3n con cookie_lru y use_cookie Si una cookie caduca desde la LRU y el indicador LRU_DISCARD est\u00e1 configurado, pero la m\u00e1quina de estado a\u00fan no se ha ejecutado, es posible que otro hilo pueda llamar a fscache_use_cookie y comenzar a usarlo. Cuando finalmente se ejecuta cookie_worker, ver\u00e1 el indicador LRU_DISCARD configurado, har\u00e1 la transici\u00f3n de cookie-&gt;state a LRU_DISCARDING, que luego retirar\u00e1 la cookie. Una vez que se retira la cookie, se elimina el objeto, se producir\u00e1n los siguientes oops porque el objeto asociado con la cookie ahora es NULL. Corrija los oops borrando el bit LRU_DISCARD si otro hilo usa la cookie antes de que se ejecute cookie_worker. ERROR: desreferencia de puntero NULL del n\u00facleo, direcci\u00f3n: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Contaminado: GE 6.0.0-5.dneg.x86_64 #1 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 26/08/2022 Cola de trabajo: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Seguimiento de llamadas: netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 hilo+0xd6/0x100"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48990.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48990",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:10.910",
"lastModified": "2024-10-21T20:15:10.910",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix use-after-free during gpu recovery\n\n[Why]\n [ 754.862560] refcount_t: underflow; use-after-free.\n [ 754.862898] Call Trace:\n [ 754.862903] <TASK>\n [ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu]\n [ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched]\n\n[How]\n The fw_fence may be not init, check whether dma_fence_init\n is performed before job free"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corregir el use after free durante la recuperaci\u00f3n de la GPU [Por qu\u00e9] [ 754.862560] refcount_t: desbordamiento; use after free. [ 754.862898] Seguimiento de llamadas: [ 754.862903] [ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu] [ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched] [C\u00f3mo] Es posible que fw_fence no se inicialice, verifique si dma_fence_init se realiza antes de la liberaci\u00f3n del trabajo"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48991.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48991",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.000",
"lastModified": "2024-10-21T20:15:11.000",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/khugepaged: invoke MMU notifiers in shmem/file collapse paths\n\nAny codepath that zaps page table entries must invoke MMU notifiers to\nensure that secondary MMUs (like KVM) don't keep accessing pages which\naren't mapped anymore. Secondary MMUs don't hold their own references to\npages that are mirrored over, so failing to notify them can lead to page\nuse-after-free.\n\nI'm marking this as addressing an issue introduced in commit f3f0e1d2150b\n(\"khugepaged: add support of collapse for tmpfs/shmem pages\"), but most of\nthe security impact of this only came in commit 27e1f8273113 (\"khugepaged:\nenable collapse pmd for pte-mapped THP\"), which actually omitted flushes\nfor the removal of present PTEs, not just for the removal of empty page\ntables."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/khugepaged: invocar notificadores MMU en rutas de colapso de shmem/archivo Cualquier ruta de c\u00f3digo que elimine las entradas de la tabla de p\u00e1ginas debe invocar notificadores MMU para garantizar que las MMU secundarias (como KVM) no sigan accediendo a p\u00e1ginas que ya no est\u00e1n asignadas. Las MMU secundarias no mantienen sus propias referencias a p\u00e1ginas que se reflejan, por lo que no notificarlas puede provocar el use-after-free de la p\u00e1gina. Estoy marcando esto como una soluci\u00f3n a un problema introducido en el commit f3f0e1d2150b (\"khugepaged: agregar compatibilidad con el colapso para p\u00e1ginas tmpfs/shmem\"), pero la mayor parte del impacto de seguridad de esto solo se produjo en el commit 27e1f8273113 (\"khugepaged: habilitar el colapso pmd para THP asignado a pte\"), que en realidad omiti\u00f3 los vaciados para la eliminaci\u00f3n de PTE actuales, no solo para la eliminaci\u00f3n de tablas de p\u00e1ginas vac\u00edas."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48992.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48992",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.067",
"lastModified": "2024-10-21T20:15:11.067",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: soc-pcm: Add NULL check in BE reparenting\n\nAdd NULL check in dpcm_be_reparent API, to handle\nkernel NULL pointer dereference error.\nThe issue occurred in fuzzing test."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: soc-pcm: Agregar comprobaci\u00f3n NULL en la reparentalizaci\u00f3n de BE Agregar comprobaci\u00f3n NULL en la API dpcm_be_reparent para manejar el error de desreferencia de puntero NULL del kernel. El problema se produjo en la prueba de fuzzing."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48994.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48994",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.257",
"lastModified": "2024-10-21T20:15:11.257",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event\n\nWith clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),\nindirect call targets are validated against the expected function\npointer prototype to make sure the call target is valid to help mitigate\nROP attacks. If they are not identical, there is a failure at run time,\nwhich manifests as either a kernel panic or thread getting killed.\n\nseq_copy_in_user() and seq_copy_in_kernel() did not have prototypes\nmatching snd_seq_dump_func_t. Adjust this and remove the casts. There\nare not resulting binary output differences.\n\nThis was found as a result of Clang's new -Wcast-function-type-strict\nflag, which is more sensitive than the simpler -Wcast-function-type,\nwhich only checks for type width mismatches."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: seq: Fix function prototipo desajuste en snd_seq_expand_var_event Con la integridad del flujo de control del kernel de clang (kCFI, CONFIG_CFI_CLANG), los objetivos de llamada indirecta se validan contra el prototipo de puntero de funci\u00f3n esperado para asegurarse de que el objetivo de llamada sea v\u00e1lido para ayudar a mitigar los ataques ROP. Si no son id\u00e9nticos, hay un error en el tiempo de ejecuci\u00f3n, que se manifiesta como un p\u00e1nico del kernel o la muerte del hilo. seq_copy_in_user() y seq_copy_in_kernel() no ten\u00edan prototipos que coincidieran con snd_seq_dump_func_t. Aj\u00fastelo y elimine las conversiones. No hay diferencias de salida binaria resultantes. Esto se encontr\u00f3 como resultado del nuevo indicador -Wcast-function-type-strict de Clang, que es m\u00e1s sensible que el m\u00e1s simple -Wcast-function-type, que solo verifica los desajustes de ancho de tipo."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48995.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48995",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.343",
"lastModified": "2024-10-21T20:15:11.343",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nInput: raydium_ts_i2c - fix memory leak in raydium_i2c_send()\n\nThere is a kmemleak when test the raydium_i2c_ts with bpf mock device:\n\n unreferenced object 0xffff88812d3675a0 (size 8):\n comm \"python3\", pid 349, jiffies 4294741067 (age 95.695s)\n hex dump (first 8 bytes):\n 11 0e 10 c0 01 00 04 00 ........\n backtrace:\n [<0000000068427125>] __kmalloc+0x46/0x1b0\n [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]\n [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts]\n [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]\n [<00000000a310de16>] i2c_device_probe+0x651/0x680\n [<00000000f5a96bf3>] really_probe+0x17c/0x3f0\n [<00000000096ba499>] __driver_probe_device+0xe3/0x170\n [<00000000c5acb4d9>] driver_probe_device+0x49/0x120\n [<00000000264fe082>] __device_attach_driver+0xf7/0x150\n [<00000000f919423c>] bus_for_each_drv+0x114/0x180\n [<00000000e067feca>] __device_attach+0x1e5/0x2d0\n [<0000000054301fc2>] bus_probe_device+0x126/0x140\n [<00000000aad93b22>] device_add+0x810/0x1130\n [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0\n [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110\n [<00000000ffec4177>] of_i2c_notify+0x100/0x160\n unreferenced object 0xffff88812d3675c8 (size 8):\n comm \"python3\", pid 349, jiffies 4294741070 (age 95.692s)\n hex dump (first 8 bytes):\n 22 00 36 2d 81 88 ff ff \".6-....\n backtrace:\n [<0000000068427125>] __kmalloc+0x46/0x1b0\n [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]\n [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts]\n [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]\n [<00000000a310de16>] i2c_device_probe+0x651/0x680\n [<00000000f5a96bf3>] really_probe+0x17c/0x3f0\n [<00000000096ba499>] __driver_probe_device+0xe3/0x170\n [<00000000c5acb4d9>] driver_probe_device+0x49/0x120\n [<00000000264fe082>] __device_attach_driver+0xf7/0x150\n [<00000000f919423c>] bus_for_each_drv+0x114/0x180\n [<00000000e067feca>] __device_attach+0x1e5/0x2d0\n [<0000000054301fc2>] bus_probe_device+0x126/0x140\n [<00000000aad93b22>] device_add+0x810/0x1130\n [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0\n [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110\n [<00000000ffec4177>] of_i2c_notify+0x100/0x160\n\nAfter BANK_SWITCH command from i2c BUS, no matter success or error\nhappened, the tx_buf should be freed."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: raydium_ts_i2c - arregla p\u00e9rdida de memoria en raydium_i2c_send() Hay una p\u00e9rdida de kmem cuando se prueba raydium_i2c_ts con bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm \"python3\", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [&lt;0000000068427125&gt;] __kmalloc+0x46/0x1b0 [&lt;0000000090180f91&gt;] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [&lt;000000006e631aee&gt;] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [&lt;00000000dc6fcf38&gt;] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [&lt;00000000a310de16&gt;] i2c_device_probe+0x651/0x680 [&lt;00000000f5a96bf3&gt;] really_probe+0x17c/0x3f0 [&lt;00000000096ba499&gt;] __driver_probe_device+0xe3/0x170 [&lt;00000000c5acb4d9&gt;] dispositivo_de_sonda_de_controlador+0x49/0x120 [&lt;00000000264fe082&gt;] __controlador_de_adjuntar_dispositivo+0xf7/0x150 [&lt;00000000f919423c&gt;] bus_para_cada_unidad+0x114/0x180 [&lt;00000000e067feca&gt;] __adjuntar_dispositivo+0x1e5/0x2d0 [&lt;0000000054301fc2&gt;] dispositivo_de_sonda_de_bus+0x126/0x140 [&lt;00000000aad93b22&gt;] dispositivo_agregar+0x810/0x1130 [&lt;00000000c086a53f&gt;] i2c_new_client_device+0x352/0x4e0 [&lt;000000003c2c248c&gt;] of_i2c_register_device+0xf1/0x110 [&lt;00000000ffec4177&gt;] of_i2c_notify+0x100/0x160 objeto sin referencia 0xffff88812d3675c8 (tama\u00f1o 8): comm \"python3\", pid 349, jiffies 4294741070 (antig\u00fcedad 95,692 s) volcado hexadecimal (primeros 8 bytes): 22 00 36 2d 81 88 ff ff \".6-.... traza inversa: [&lt;0000000068427125&gt;] __kmalloc+0x46/0x1b0 [&lt;0000000090180f91&gt;] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [&lt;000000001d5c9620&gt;] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [&lt;00000000dc6fcf38&gt;] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [&lt;00000000a310de16&gt;] i2c_device_probe+0x651/0x680 [&lt;00000000f5a96bf3&gt;] realmente_sondeo+0x17c/0x3f0 [&lt;00000000096ba499&gt;] __dispositivo_de_sonda_de_controlador+0xe3/0x170 [&lt;00000000c5acb4d9&gt;] dispositivo_de_sonda_de_controlador+0x49/0x120 [&lt;00000000264fe082&gt;] __dispositivo_adjunto_controlador+0xf7/0x150 [&lt;00000000f919423c&gt;] bus_para_cada_unidad+0x114/0x180 [&lt;00000000e067feca&gt;] __dispositivo_adjunto+0x1e5/0x2d0 [&lt;0000000054301fc2&gt;] bus_probe_device+0x126/0x140 [&lt;00000000aad93b22&gt;] device_add+0x810/0x1130 [&lt;00000000c086a53f&gt;] i2c_new_client_device+0x352/0x4e0 [&lt;000000003c2c248c&gt;] of_i2c_register_device+0xf1/0x110 [&lt;00000000ffec4177&gt;] of_i2c_notify+0x100/0x160 Despu\u00e9s del comando BANK_SWITCH del BUS i2c, sin importar si se produjo un \u00e9xito o un error, se debe liberar el tx_buf."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48996.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48996",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.423",
"lastModified": "2024-10-21T20:15:11.423",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes()\n\nCommit da87878010e5 (\"mm/damon/sysfs: support online inputs update\") made\n'damon_sysfs_set_schemes()' to be called for running DAMON context, which\ncould have schemes. In the case, DAMON sysfs interface is supposed to\nupdate, remove, or add schemes to reflect the sysfs files. However, the\ncode is assuming the DAMON context wouldn't have schemes at all, and\ntherefore creates and adds new schemes. As a result, the code doesn't\nwork as intended for online schemes tuning and could have more than\nexpected memory footprint. The schemes are all in the DAMON context, so\nit doesn't leak the memory, though.\n\nRemove the wrong asssumption (the DAMON context wouldn't have schemes) in\n'damon_sysfs_set_schemes()' to fix the bug."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/sysfs: se corrige la suposici\u00f3n incorrecta de esquemas vac\u00edos durante el ajuste en l\u00ednea en damon_sysfs_set_schemes(). el commit da87878010e5 (\"mm/damon/sysfs: soporte para la actualizaci\u00f3n de entradas en l\u00ednea\") hizo que se llamara a 'damon_sysfs_set_schemes()' para ejecutar el contexto DAMON, que podr\u00eda tener esquemas. En este caso, se supone que la interfaz sysfs de DAMON actualiza, elimina o agrega esquemas para reflejar los archivos sysfs. Sin embargo, el c\u00f3digo asume que el contexto DAMON no tendr\u00eda esquemas en absoluto y, por lo tanto, crea y agrega nuevos esquemas. Como resultado, el c\u00f3digo no funciona como se esperaba para el ajuste de esquemas en l\u00ednea y podr\u00eda tener una huella de memoria mayor a la esperada. Todos los esquemas est\u00e1n en el contexto DAMON, por lo que no pierde memoria. Elimine la suposici\u00f3n incorrecta (el contexto DAMON no tendr\u00eda esquemas) en 'damon_sysfs_set_schemes()' para corregir el error."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48997.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48997",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.503",
"lastModified": "2024-10-21T20:15:11.503",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nchar: tpm: Protect tpm_pm_suspend with locks\n\nCurrently tpm transactions are executed unconditionally in\ntpm_pm_suspend() function, which may lead to races with other tpm\naccessors in the system.\n\nSpecifically, the hw_random tpm driver makes use of tpm_get_random(),\nand this function is called in a loop from a kthread, which means it's\nnot frozen alongside userspace, and so can race with the work done\nduring system suspend:\n\n tpm tpm0: tpm_transmit: tpm_recv: error -52\n tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics\n CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014\n Call Trace:\n tpm_tis_status.cold+0x19/0x20\n tpm_transmit+0x13b/0x390\n tpm_transmit_cmd+0x20/0x80\n tpm1_pm_suspend+0xa6/0x110\n tpm_pm_suspend+0x53/0x80\n __pnp_bus_suspend+0x35/0xe0\n __device_suspend+0x10f/0x350\n\nFix this by calling tpm_try_get_ops(), which itself is a wrapper around\ntpm_chip_start(), but takes the appropriate mutex.\n\n[Jason: reworked commit message, added metadata]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: char: tpm: Proteger tpm_pm_suspend con bloqueos Actualmente, las transacciones tpm se ejecutan incondicionalmente en la funci\u00f3n tpm_pm_suspend(), lo que puede generar ejecuciones con otros accesores tpm en el sistema. Espec\u00edficamente, el controlador tpm hw_random hace uso de tpm_get_random(), y esta funci\u00f3n se llama en un bucle desde un kthread, lo que significa que no est\u00e1 congelada junto con el espacio de usuario, y por lo tanto puede competir con el trabajo realizado durante la suspensi\u00f3n del sistema: tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: TPM_STS.x 0xff no v\u00e1lido, volcando pila para an\u00e1lisis forense CPU: 0 PID: 1 Comm: init No contaminado 6.1.0-rc5+ #135 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Rastreo de llamadas: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350 Solucione este problema llamando a tpm_try_get_ops(), que es un contenedor de tpm_chip_start(), pero toma el mutex apropiado. [Jason: mensaje de confirmaci\u00f3n redise\u00f1ado, metadatos agregados]"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48998.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48998",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.570",
"lastModified": "2024-10-21T20:15:11.570",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/bpf/32: Fix Oops on tail call tests\n\ntest_bpf tail call tests end up as:\n\n test_bpf: #0 Tail call leaf jited:1 85 PASS\n test_bpf: #1 Tail call 2 jited:1 111 PASS\n test_bpf: #2 Tail call 3 jited:1 145 PASS\n test_bpf: #3 Tail call 4 jited:1 170 PASS\n test_bpf: #4 Tail call load/store leaf jited:1 190 PASS\n test_bpf: #5 Tail call load/store jited:1\n BUG: Unable to handle kernel data access on write at 0xf1b4e000\n Faulting instruction address: 0xbe86b710\n Oops: Kernel access of bad area, sig: 11 [#1]\n BE PAGE_SIZE=4K MMU=Hash PowerMac\n Modules linked in: test_bpf(+)\n CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ #195\n Hardware name: PowerMac3,1 750CL 0x87210 PowerMac\n NIP: be86b710 LR: be857e88 CTR: be86b704\n REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+)\n MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28008242 XER: 00000000\n DAR: f1b4e000 DSISR: 42000000\n GPR00: 00000001 f1b4dfe0 c11d2280 00000000 00000000 00000000 00000002 00000000\n GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8\n GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000\n GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00\n NIP [be86b710] 0xbe86b710\n LR [be857e88] __run_one+0xec/0x264 [test_bpf]\n Call Trace:\n [f1b4dfe0] [00000002] 0x2 (unreliable)\n Instruction dump:\n XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX\n XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX\n ---[ end trace 0000000000000000 ]---\n\nThis is a tentative to write above the stack. The problem is encoutered\nwith tests added by commit 38608ee7b690 (\"bpf, tests: Add load store\ntest case for tail call\")\n\nThis happens because tail call is done to a BPF prog with a different\nstack_depth. At the time being, the stack is kept as is when the caller\ntail calls its callee. But at exit, the callee restores the stack based\non its own properties. Therefore here, at each run, r1 is erroneously\nincreased by 32 - 16 = 16 bytes.\n\nThis was done that way in order to pass the tail call count from caller\nto callee through the stack. As powerpc32 doesn't have a red zone in\nthe stack, it was necessary the maintain the stack as is for the tail\ncall. But it was not anticipated that the BPF frame size could be\ndifferent.\n\nLet's take a new approach. Use register r4 to carry the tail call count\nduring the tail call, and save it into the stack at function entry if\nrequired. This means the input parameter must be in r3, which is more\ncorrect as it is a 32 bits parameter, then tail call better match with\nnormal BPF function entry, the down side being that we move that input\nparameter back and forth between r3 and r4. That can be optimised later.\n\nDoing that also has the advantage of maximising the common parts between\ntail calls and a normal function exit.\n\nWith the fix, tail call tests are now successfull:\n\n test_bpf: #0 Tail call leaf jited:1 53 PASS\n test_bpf: #1 Tail call 2 jited:1 115 PASS\n test_bpf: #2 Tail call 3 jited:1 154 PASS\n test_bpf: #3 Tail call 4 jited:1 165 PASS\n test_bpf: #4 Tail call load/store leaf jited:1 101 PASS\n test_bpf: #5 Tail call load/store jited:1 141 PASS\n test_bpf: #6 Tail call error path, max count reached jited:1 994 PASS\n test_bpf: #7 Tail call count preserved across function calls jited:1 140975 PASS\n test_bpf: #8 Tail call error path, NULL target jited:1 110 PASS\n test_bpf: #9 Tail call error path, index out of range jited:1 69 PASS\n test_bpf: test_tail_calls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT'ed]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/bpf/32: Se ha corregido el error Oops en las pruebas de llamadas de cola. Las pruebas de llamadas de cola test_bpf terminan como: test_bpf: #0 Tail call leaf jited:1 85 PASS test_bpf: #1 Tail call 2 jited:1 111 PASS test_bpf: #2 Tail call 3 jited:1 145 PASS test_bpf: #3 Tail call 4 jited:1 170 PASS test_bpf: #4 Tail call load/store leaf jited:1 190 PASS test_bpf: #5 Tail call load/store jited:1 ERROR: No se puede manejar el acceso a los datos del kernel en escritura en 0xf1b4e000 Direcci\u00f3n de instrucci\u00f3n err\u00f3nea: 0xbe86b710 Oops: Acceso al kernel de un \u00e1rea defectuosa, firma: 11 [#1] BE PAGE_SIZE=4K MMU=Hash M\u00f3dulos PowerMac vinculados en: test_bpf(+) CPU: 0 PID: 97 Comm: insmod No contaminado 6.1.0-rc4+ #195 Nombre del hardware: PowerMac3,1 750CL 0x87210 PowerMac NIP: be86b710 LR: be857e88 CTR: be86b704 REGS: f1b4df20 TRAP: 0300 No contaminado (6.1.0-rc4+) MSR: 00009032 CR: 28008242 XER: 00000000 DAR: f1b4e000 DSISR: 42000000 GPR00: 00000001 f1b4dfe0 c11d2280 00000000 00000000 00000000 00000002 00000000 GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8 GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000 GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00 NIP [be86b710] 0xbe86b710 LR [be857e88] __run_one+0xec/0x264 [test_bpf] Seguimiento de llamada: [f1b4dfe0] [00000002] 0x2 (no confiable) Volcado de instrucci\u00f3n: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ fin del seguimiento 000000000000000 ]--- Esto es una tentativa de escribir sobre la pila. El problema se encuentra con las pruebas agregadas por el commit 38608ee7b690 (\"bpf, pruebas: Agregar caso de prueba de almacenamiento de carga para llamada de cola\") Esto sucede porque la llamada de cola se realiza a un programa BPF con una profundidad de pila diferente. En ese momento, la pila se mantiene como est\u00e1 cuando el llamador llama a la cola de su llamado. Pero al salir, el llamado restaura la pila en funci\u00f3n de sus propias propiedades. Por lo tanto, aqu\u00ed, en cada ejecuci\u00f3n, r1 se incrementa err\u00f3neamente en 32 - 16 = 16 bytes. Esto se hizo de esa manera para pasar el recuento de llamadas de cola del llamador al llamado a trav\u00e9s de la pila. Como powerpc32 no tiene una zona roja en la pila, fue necesario mantener la pila como est\u00e1 para la llamada de cola. Pero no se anticip\u00f3 que el tama\u00f1o del marco BPF podr\u00eda ser diferente. Tomemos un nuevo enfoque. Use el registro r4 para llevar el recuento de llamadas de cola durante la llamada de cola y gu\u00e1rdelo en la pila en la entrada de la funci\u00f3n si es necesario. Esto significa que el par\u00e1metro de entrada debe estar en r3, lo cual es m\u00e1s correcto ya que es un par\u00e1metro de 32 bits, por lo que la llamada de cola coincide mejor con la entrada de la funci\u00f3n BPF normal, la desventaja es que movemos ese par\u00e1metro de entrada de ida y vuelta entre r3 y r4. Esto se puede optimizar m\u00e1s adelante. Hacer eso tambi\u00e9n tiene la ventaja de maximizar las partes comunes entre las llamadas de cola y una salida de funci\u00f3n normal. Con la correcci\u00f3n, las pruebas de llamadas de cola ahora son exitosas: test_bpf: #0 Hoja de llamada de cola jited:1 53 PASS test_bpf: #1 Llamada de cola 2 jited:1 115 PASS test_bpf: #2 Llamada de cola 3 jited:1 154 PASS test_bpf: #3 Llamada de cola 4 jited:1 165 PASS test_bpf: #4 Hoja de carga/almacenamiento de llamadas de cola jited:1 101 PASS test_bpf: #5 Carga/almacenamiento de llamadas de cola jited:1 141 PASS test_bpf: #6 Ruta de error de llamada de cola, recuento m\u00e1ximo alcanzado jited:1 994 PASS test_bpf: #7 Recuento de llamadas de cola conservado en todas las llamadas de funci\u00f3n jited:1 140975 PASS test_bpf: #8 Ruta de error de llamada de cola, objetivo NULL jited:1 110 PASS test_bpf: #9 --- truncado ----"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-489xx/CVE-2022-48999.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-48999",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.630",
"lastModified": "2024-10-21T20:15:11.630",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: Handle attempt to delete multipath route when fib_info contains an nh reference\n\nGwangun Jung reported a slab-out-of-bounds access in fib_nh_match:\n fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961\n fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753\n inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874\n\nSeparate nexthop objects are mutually exclusive with the legacy\nmultipath spec. Fix fib_nh_match to return if the config for the\nto be deleted route contains a multipath spec while the fib_info\nis using a nexthop object."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4: Controlar el intento de eliminar una ruta multipath cuando fib_info contiene una referencia nh Gwangun Jung inform\u00f3 un acceso fuera de los l\u00edmites en fib_nh_match: fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961 fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753 inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874 Los objetos de siguiente salto separados son mutuamente excluyentes con la especificaci\u00f3n multipath heredada. Arreglar fib_nh_match para que regrese si la configuraci\u00f3n de la ruta que se va a eliminar contiene una especificaci\u00f3n de rutas m\u00faltiples mientras fib_info usa un objeto nexthop."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49000.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49000",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.710",
"lastModified": "2024-10-21T20:15:11.710",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Fix PCI device refcount leak in has_external_pci()\n\nfor_each_pci_dev() is implemented by pci_get_device(). The comment of\npci_get_device() says that it will increase the reference count for the\nreturned pci_dev and also decrease the reference count for the input\npci_dev @from if it is not NULL.\n\nIf we break for_each_pci_dev() loop with pdev not NULL, we need to call\npci_dev_put() to decrease the reference count. Add the missing\npci_dev_put() before 'return true' to avoid reference count leak."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se soluciona la fuga de recuento de referencias del dispositivo PCI en has_external_pci(). for_each_pci_dev() se implementa mediante pci_get_device(). El comentario de pci_get_device() dice que aumentar\u00e1 el recuento de referencias para el pci_dev devuelto y tambi\u00e9n disminuir\u00e1 el recuento de referencias para el pci_dev de entrada @from si no es NULL. Si interrumpimos el bucle for_each_pci_dev() con pdev no NULL, debemos llamar a pci_dev_put() para disminuir el recuento de referencias. Agregue el pci_dev_put() faltante antes de 'return true' para evitar la fuga del recuento de referencias."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49001.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49001",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.773",
"lastModified": "2024-10-21T20:15:11.773",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: fix race when vmap stack overflow\n\nCurrently, when detecting vmap stack overflow, riscv firstly switches\nto the so called shadow stack, then use this shadow stack to call the\nget_overflow_stack() to get the overflow stack. However, there's\na race here if two or more harts use the same shadow stack at the same\ntime.\n\nTo solve this race, we introduce spin_shadow_stack atomic var, which\nwill be swap between its own address and 0 in atomic way, when the\nvar is set, it means the shadow_stack is being used; when the var\nis cleared, it means the shadow_stack isn't being used.\n\n[Palmer: Add AQ to the swap, and also some comments.]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: arregla la ejecuci\u00f3n cuando se desborda la pila de vmap Actualmente, al detectar un desbordamiento de la pila de vmap, riscv primero cambia a la llamada pila de sombra, luego usa esta pila de sombra para llamar a get_overflow_stack() para obtener la pila de desbordamiento. Sin embargo, aqu\u00ed hay una ejecuci\u00f3n si dos o m\u00e1s harts usan la misma pila de sombra al mismo tiempo. Para resolver esta ejecuci\u00f3n, introducimos la variable at\u00f3mica spin_shadow_stack, que se intercambiar\u00e1 entre su propia direcci\u00f3n y 0 de forma at\u00f3mica, cuando la variable est\u00e1 configurada, significa que se est\u00e1 usando shadow_stack; cuando la variable se borra, significa que no se est\u00e1 usando shadow_stack. [Palmer: Agrega AQ al intercambio y tambi\u00e9n algunos comentarios]."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49002.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49002",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.853",
"lastModified": "2024-10-21T20:15:11.853",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()\n\nfor_each_pci_dev() is implemented by pci_get_device(). The comment of\npci_get_device() says that it will increase the reference count for the\nreturned pci_dev and also decrease the reference count for the input\npci_dev @from if it is not NULL.\n\nIf we break for_each_pci_dev() loop with pdev not NULL, we need to call\npci_dev_put() to decrease the reference count. Add the missing\npci_dev_put() for the error path to avoid reference count leak."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige la p\u00e9rdida de recuento de referencias del dispositivo PCI en dmar_dev_scope_init(). for_each_pci_dev() se implementa mediante pci_get_device(). El comentario de pci_get_device() dice que aumentar\u00e1 el recuento de referencias para el pci_dev devuelto y tambi\u00e9n disminuir\u00e1 el recuento de referencias para el pci_dev de entrada @from si no es NULL. Si interrumpimos el bucle for_each_pci_dev() con pdev no NULL, debemos llamar a pci_dev_put() para disminuir el recuento de referencias. Agregue el pci_dev_put() faltante para la ruta de error para evitar la p\u00e9rdida del recuento de referencias."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49003.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49003",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.920",
"lastModified": "2024-10-21T20:15:11.920",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix SRCU protection of nvme_ns_head list\n\nWalking the nvme_ns_head siblings list is protected by the head's srcu\nin nvme_ns_head_submit_bio() but not nvme_mpath_revalidate_paths().\nRemoving namespaces from the list also fails to synchronize the srcu.\nConcurrent scan work can therefore cause use-after-frees.\n\nHold the head's srcu lock in nvme_mpath_revalidate_paths() and\nsynchronize with the srcu, not the global RCU, in nvme_ns_remove().\n\nObserved the following panic when making NVMe/RDMA connections\nwith native multipath on the Rocky Linux 8.6 kernel\n(it seems the upstream kernel has the same race condition).\nDisassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx;\ncomputing capacity != get_capacity(ns->disk).\nAddress 0x50 is dereferenced because ns->disk is NULL.\nThe NULL disk appears to be the result of concurrent scan work\nfreeing the namespace (note the log line in the middle of the panic).\n\n[37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050\n[37314.206036] nvme0n3: detected capacity change from 0 to 11811160064\n[37314.299753] PGD 0 P4D 0\n[37314.299756] Oops: 0000 [#1] SMP PTI\n[37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1\n[37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018\n[37314.299763] Workqueue: nvme-wq nvme_scan_work [nvme_core]\n[37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core]\n[37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3\n[37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202\n[37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000\n[37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800\n[37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff\n[37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000\n[37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000\n[37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000\n[37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0\n[37315.799267] Call Trace:\n[37315.828515] nvme_update_ns_info+0x1ac/0x250 [nvme_core]\n[37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [nvme_core]\n[37315.961871] ? __blk_mq_free_request+0x6b/0x90\n[37316.015021] nvme_scan_work+0x151/0x240 [nvme_core]\n[37316.073371] process_one_work+0x1a7/0x360\n[37316.121318] ? create_worker+0x1a0/0x1a0\n[37316.168227] worker_thread+0x30/0x390\n[37316.212024] ? create_worker+0x1a0/0x1a0\n[37316.258939] kthread+0x10a/0x120\n[37316.297557] ? set_kthread_struct+0x50/0x50\n[37316.347590] ret_from_fork+0x35/0x40\n[37316.390360] Modules linked in: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc overlay nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me pcspkr ipmi_devintf mei lpc_ich wmi ipmi_msghandler acpi_power_meter ex\n---truncated---"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme: se corrige la protecci\u00f3n SRCU de la lista nvme_ns_head El recorrido por la lista de hermanos nvme_ns_head est\u00e1 protegido por el srcu del cabezal en nvme_ns_head_submit_bio() pero no por nvme_mpath_revalidate_paths(). La eliminaci\u00f3n de espacios de nombres de la lista tambi\u00e9n fallo al sincronizar el srcu. Por lo tanto, el trabajo de escaneo simult\u00e1neo puede causar use-after-free. Mantenga el bloqueo del srcu del cabezal en nvme_mpath_revalidate_paths() y sincronice con el srcu, no con el RCU global, en nvme_ns_remove(). Se observ\u00f3 el siguiente p\u00e1nico al realizar conexiones NVMe/RDMA con multipath nativo en el kernel Rocky Linux 8.6 (parece que el kernel ascendente tiene la misma condici\u00f3n de ejecuci\u00f3n). El desensamblaje muestra que la instrucci\u00f3n que fallo es cmp 0x50(%rdx),%rcx; capacidad de c\u00f3mputo != get_capacity(ns-&gt;disk). La direcci\u00f3n 0x50 est\u00e1 desreferenciada porque ns-&gt;disk es NULL. El disco NULL parece ser el resultado de un trabajo de escaneo simult\u00e1neo que libera el espacio de nombres (observe la l\u00ednea de registro en el medio del p\u00e1nico). [37314.206036] ERROR: no se puede manejar la desreferencia del puntero NULL del n\u00facleo en 0000000000000050 [37314.206036] nvme0n3: se detect\u00f3 un cambio de capacidad de 0 a 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: cargado Tainted: GWX --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1 [37314.299762] Nombre del hardware: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 23/05/2018 [37314.299763] Cola de trabajo: nvme-wq nvme_scan_work [nvme_core] [37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core] [37314.299790] C\u00f3digo: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 &lt;48&gt; 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [37315.713871] CR2: 000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Seguimiento de llamadas: [37315.828515] nvme_update_ns_info+0x1ac/0x250 [n\u00facleo_nvme] [37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [n\u00facleo_nvme] [37315.961871] ? __blk_mq_free_request+0x6b/0x90 [37316.015021] nvme_scan_work+0x151/0x240 [n\u00facleo_nvme] [37316.073371] process_one_work+0x1a7/0x360 [37316.121318] ? crear_trabajador+0x1a0/0x1a0 [37316.168227] subproceso_trabajador+0x30/0x390 [37316.212024] ? crear_trabajador+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? M\u00f3dulos vinculados en: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc superposici\u00f3n nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me---truncado---"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49004.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49004",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:11.990",
"lastModified": "2024-10-21T20:15:11.990",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Sync efi page table's kernel mappings before switching\n\nThe EFI page table is initially created as a copy of the kernel page table.\nWith VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area:\nif the stack is allocated in a new PGD (one that was not present at the\nmoment of the efi page table creation or not synced in a previous vmalloc\nfault), the kernel will take a trap when switching to the efi page table\nwhen the vmalloc kernel stack is accessed, resulting in a kernel panic.\n\nFix that by updating the efi kernel mappings before switching to the efi\npage table."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: Sincronizar las asignaciones de kernel de la tabla de p\u00e1ginas efi antes de cambiar La tabla de p\u00e1ginas efi se crea inicialmente como una copia de la tabla de p\u00e1ginas del kernel. Con VMAP_STACK habilitado, las pilas del kernel se asignan en el \u00e1rea vmalloc: si la pila se asigna en un nuevo PGD (uno que no estaba presente en el momento de la creaci\u00f3n de la tabla de p\u00e1ginas efi o no se sincroniz\u00f3 en un error vmalloc anterior), el kernel tomar\u00e1 una trampa al cambiar a la tabla de p\u00e1ginas efi cuando se accede a la pila del kernel vmalloc, lo que resulta en un p\u00e1nico del kernel. Solucione eso actualizando las asignaciones de kernel efi antes de cambiar a la tabla de p\u00e1ginas efi."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49005.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49005",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.040",
"lastModified": "2024-10-21T20:15:12.040",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: ops: Fix bounds check for _sx controls\n\nFor _sx controls the semantics of the max field is not the usual one, max\nis the number of steps rather than the maximum value. This means that our\ncheck in snd_soc_put_volsw_sx() needs to just check against the maximum\nvalue."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: ops: Fix bounds check for _sx controls Para los controles _sx, la sem\u00e1ntica del campo max no es la habitual, max es el n\u00famero de pasos en lugar del valor m\u00e1ximo. Esto significa que nuestra comprobaci\u00f3n en snd_soc_put_volsw_sx() solo debe comprobarse con el valor m\u00e1ximo."
}
],
"metrics": {},

10
CVE-2022/CVE-2022-490xx/CVE-2022-49006.json
View File

File diff suppressed because one or more lines are too long

8
CVE-2022/CVE-2022-490xx/CVE-2022-49007.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49007",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.197",
"lastModified": "2024-10-21T20:15:12.197",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()\n\nSyzbot reported a null-ptr-deref bug:\n\n NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP\n frequency < 30 seconds\n general protection fault, probably for non-canonical address\n 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n CPU: 1 PID: 3603 Comm: segctord Not tainted\n 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0\n Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google\n 10/11/2022\n RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0\n fs/nilfs2/alloc.c:608\n Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00\n 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02\n 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7\n RSP: 0018:ffffc90003dff830 EFLAGS: 00010212\n RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d\n RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010\n RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f\n R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158\n R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004\n FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000)\n knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0\n Call Trace:\n <TASK>\n nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline]\n nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193\n nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236\n nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940\n nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline]\n nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline]\n nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088\n nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337\n nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568\n nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018\n nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067\n nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline]\n nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline]\n nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045\n nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379\n nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline]\n nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570\n kthread+0x2e4/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n </TASK>\n ...\n\nIf DAT metadata file is corrupted on disk, there is a case where\nreq->pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during\na b-tree operation that cascadingly updates ancestor nodes of the b-tree,\nbecause nilfs_dat_commit_alloc() for a lower level block can initialize\nthe blocknr on the same DAT entry between nilfs_dat_prepare_end() and\nnilfs_dat_commit_end().\n\nIf this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free()\nwithout valid buffer heads in req->pr_desc_bh and req->pr_bitmap_bh, and\ncauses the NULL pointer dereference above in\nnilfs_palloc_commit_free_entry() function, which leads to a crash.\n\nFix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh\nbefore nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free().\n\nThis also calls nilfs_error() in that case to notify that there is a fatal\nflaw in the filesystem metadata and prevent further operations."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige la desreferencia de puntero NULL en nilfs_palloc_commit_free_entry() Syzbot inform\u00f3 un error de desreferencia de puntero nulo: NILFS (loop0): segctord iniciando. Intervalo de construcci\u00f3n = 5 segundos, frecuencia de CP &lt; 30 segundos. fallo de protecci\u00f3n general, probablemente para direcci\u00f3n no can\u00f3nica 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en rango [0x000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord No contaminado 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 C\u00f3digo: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 ser a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc00000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 00000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Seguimiento de llamadas: nilfs_dat_commit_free fs/nilfs2/dat.c:114 [en l\u00ednea] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [en l\u00ednea] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [en l\u00ednea] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [en l\u00ednea] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [en l\u00ednea] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [en l\u00ednea] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 ... Si el archivo de metadatos DAT est\u00e1 da\u00f1ado en el disco, existe un caso en el que req-&gt;pr_desc_bh es NULL y blocknr es 0 en nilfs_dat_commit_end() durante una operaci\u00f3n de \u00e1rbol b que actualiza en cascada los nodos ancestros del \u00e1rbol b, porque nilfs_dat_commit_alloc() para un bloque de nivel inferior puede inicializar el blocknr en la misma entrada DAT entre nilfs_dat_prepare_end() y nilfs_dat_commit_end(). Si esto sucede, nilfs_dat_commit_end() llama a nilfs_dat_commit_free() sin encabezados de b\u00fafer v\u00e1lidos en req-&gt;pr_desc_bh y req-&gt;pr_bitmap_bh, y provoca la desreferencia del puntero NULL anterior en la funci\u00f3n nilfs_palloc_commit_free_entry(), lo que provoca un bloqueo. Solucione este problema agregando una comprobaci\u00f3n NULL en req-&gt;pr_desc_bh y req-&gt;pr_bitmap_bh antes de nilfs_palloc_commit_free_entry() en nilfs_dat_commit_free(). Esto tambi\u00e9n llama a nilfs_error() en ese caso para notificar que hay un fallo fatal en los metadatos del sistema de archivos y evitar operaciones futuras."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49008.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49008",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.290",
"lastModified": "2024-10-21T20:15:12.290",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: can327: can327_feed_frame_to_netdev(): fix potential skb leak when netdev is down\n\nIn can327_feed_frame_to_netdev(), it did not free the skb when netdev\nis down, and all callers of can327_feed_frame_to_netdev() did not free\nallocated skb too. That would trigger skb leak.\n\nFix it by adding kfree_skb() in can327_feed_frame_to_netdev() when netdev\nis down. Not tested, just compiled."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: can327: can327_feed_frame_to_netdev(): corrige una posible fuga de skb cuando netdev est\u00e1 inactivo En can327_feed_frame_to_netdev(), no liberaba el skb cuando netdev estaba inactivo, y todos los que llamaban a can327_feed_frame_to_netdev() tampoco liberaban el skb asignado. Eso desencadenar\u00eda una fuga de skb. Arr\u00e9glelo a\u00f1adiendo kfree_skb() en can327_feed_frame_to_netdev() cuando netdev est\u00e9 inactivo. No probado, solo compilado."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49009.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49009",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.373",
"lastModified": "2024-10-21T20:15:12.373",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (asus-ec-sensors) Add checks for devm_kcalloc\n\nAs the devm_kcalloc may return NULL, the return value needs to be checked\nto avoid NULL poineter dereference."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (asus-ec-sensors) Agregar comprobaciones para devm_kcalloc Como devm_kcalloc puede devolver NULL, se debe comprobar el valor de retorno para evitar la desreferencia del puntero NULL."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49010.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49010",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.433",
"lastModified": "2024-10-21T20:15:12.433",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (coretemp) Check for null before removing sysfs attrs\n\nIf coretemp_add_core() gets an error then pdata->core_data[indx]\nis already NULL and has been kfreed. Don't pass that to\nsysfs_remove_group() as that will crash in sysfs_remove_group().\n\n[Shortened for readability]\n[91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'\n<cpu offline>\n[91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188\n[91855.165103] #PF: supervisor read access in kernel mode\n[91855.194506] #PF: error_code(0x0000) - not-present page\n[91855.224445] PGD 0 P4D 0\n[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI\n...\n[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80\n...\n[91855.796571] Call Trace:\n[91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp]\n[91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp]\n[91855.871107] cpuhp_invoke_callback+0x105/0x4b0\n[91855.893432] cpuhp_thread_fun+0x8e/0x150\n...\n\nFix this by checking for NULL first."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (coretemp) Verificar si hay valores nulos antes de eliminar los atributos de sysfs Si coretemp_add_core() obtiene un error, entonces pdata-&gt;core_data[indx] ya es NULL y se ha liberado. No pase eso a sysfs_remove_group() ya que eso bloquear\u00e1 sysfs_remove_group(). [Abreviado para facilitar la lectura] [91854.020159] sysfs: no se puede crear un nombre de archivo duplicado '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label' [91855.126115] ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 0000000000000188 [91855.165103] #PF: acceso de lectura del supervisor en modo kernel [91855.194506] #PF: error_code(0x0000) - p\u00e1gina no presente [91855.224445] PGD 0 P4D 0 [91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI ... [91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80 ... [91855.796571] Seguimiento de llamadas: [91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp] [91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp] [91855.871107] cpuhp_invoke_callback+0x105/0x4b0 [91855.893432] cpuhp_thread_fun+0x8e/0x150 ... Solucione esto comprobando primero si es NULL."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49011.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49011",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.500",
"lastModified": "2024-10-21T20:15:12.500",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()\n\nAs comment of pci_get_domain_bus_and_slot() says, it returns\na pci device with refcount increment, when finish using it,\nthe caller must decrement the reference count by calling\npci_dev_put(). So call it after using to avoid refcount leak."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (coretemp) corrige la p\u00e9rdida de recuento de referencias del dispositivo pci en nv1a_ram_new() Como dice el comentario de pci_get_domain_bus_and_slot(), devuelve un dispositivo pci con un incremento de recuento de referencias, cuando termina de usarlo, el llamador debe disminuir el recuento de referencias llamando a pci_dev_put(). Por lo tanto, ll\u00e1melo despu\u00e9s de usarlo para evitar la p\u00e9rdida de recuento de referencias."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49012.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49012",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.573",
"lastModified": "2024-10-21T20:15:12.573",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix server->active leak in afs_put_server\n\nThe atomic_read was accidentally replaced with atomic_inc_return,\nwhich prevents the server from getting cleaned up and causes rmmod\nto hang with a warning:\n\n Can't purge s=00000001"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: Se corrige la fuga de server-&gt;active en afs_put_server. atomic_read se reemplaz\u00f3 accidentalmente con atomic_inc_return, lo que evita que se limpie el servidor y hace que rmmod se cuelgue con una advertencia: No se puede purgar s=00000001"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49013.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49013",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.637",
"lastModified": "2024-10-21T20:15:12.637",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:13:25.583",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix memory leak in sctp_stream_outq_migrate()\n\nWhen sctp_stream_outq_migrate() is called to release stream out resources,\nthe memory pointed to by prio_head in stream out is not released.\n\nThe memory leak information is as follows:\n unreferenced object 0xffff88801fe79f80 (size 64):\n comm \"sctp_repo\", pid 7957, jiffies 4294951704 (age 36.480s)\n hex dump (first 32 bytes):\n 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................\n 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................\n backtrace:\n [<ffffffff81b215c6>] kmalloc_trace+0x26/0x60\n [<ffffffff88ae517c>] sctp_sched_prio_set+0x4cc/0x770\n [<ffffffff88ad64f2>] sctp_stream_init_ext+0xd2/0x1b0\n [<ffffffff88aa2604>] sctp_sendmsg_to_asoc+0x1614/0x1a30\n [<ffffffff88ab7ff1>] sctp_sendmsg+0xda1/0x1ef0\n [<ffffffff87f765ed>] inet_sendmsg+0x9d/0xe0\n [<ffffffff8754b5b3>] sock_sendmsg+0xd3/0x120\n [<ffffffff8755446a>] __sys_sendto+0x23a/0x340\n [<ffffffff87554651>] __x64_sys_sendto+0xe1/0x1b0\n [<ffffffff89978b49>] do_syscall_64+0x39/0xb0\n [<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: se corrige la p\u00e9rdida de memoria en sctp_stream_outq_migrate() Cuando se llama a sctp_stream_outq_migrate() para liberar recursos de salida de flujo, la memoria a la que apunta prio_head en salida de flujo no se libera. La informaci\u00f3n de p\u00e9rdida de memoria es la siguiente: objeto sin referencia 0xffff88801fe79f80 (tama\u00f1o 64): comm \"sctp_repo\", pid 7957, jiffies 4294951704 (edad 36.480s) volcado hexadecimal (primeros 32 bytes): 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................ 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................ backtrace: [] kmalloc_trace+0x26/0x60 [] sctp_sched_prio_set+0x4cc/0x770 [] sctp_stream_init_ext+0xd2/0x1b0 [] sctp_sendmsg_to_asoc+0x1614/0x1a30 [] sctp_sendmsg+0xda1/0x1ef0 [] inet_sendmsg+0x9d/0xe0 [] sock_sendmsg+0xd3/0x120 [] __sys_sendto+0x23a/0x340 [] __x64_sys_sendto+0xe1/0x1b0 [] hacer_llamada_al_sistema_64+0x39/0xb0 [] entrada_LLAMADA_AL_SISTEMA_64_despu\u00e9s_de_hwframe+0x63/0xcd"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49014.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49014",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.707",
"lastModified": "2024-10-21T20:15:12.707",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tun: Fix use-after-free in tun_detach()\n\nsyzbot reported use-after-free in tun_detach() [1]. This causes call\ntrace like below:\n\n==================================================================\nBUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75\nRead of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673\n\nCPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:284 [inline]\n print_report+0x15e/0x461 mm/kasan/report.c:395\n kasan_report+0xbf/0x1f0 mm/kasan/report.c:495\n notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75\n call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942\n call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]\n call_netdevice_notifiers net/core/dev.c:1997 [inline]\n netdev_wait_allrefs_any net/core/dev.c:10237 [inline]\n netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351\n tun_detach drivers/net/tun.c:704 [inline]\n tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467\n __fput+0x27c/0xa90 fs/file_table.c:320\n task_work_run+0x16f/0x270 kernel/task_work.c:179\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0xb3d/0x2a30 kernel/exit.c:820\n do_group_exit+0xd4/0x2a0 kernel/exit.c:950\n get_signal+0x21b1/0x2440 kernel/signal.c:2858\n arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869\n exit_to_user_mode_loop kernel/entry/common.c:168 [inline]\n exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203\n __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]\n syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296\n do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe cause of the issue is that sock_put() from __tun_detach() drops\nlast reference count for struct net, and then notifier_call_chain()\nfrom netdev_state_change() accesses that struct net.\n\nThis patch fixes the issue by calling sock_put() from tun_detach()\nafter all necessary accesses for the struct net has done."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tun: Se corrige el use after free en tun_detach() syzbot inform\u00f3 use after free en tun_detach() [1]. Esto provoca un seguimiento de llamadas como el siguiente: ==================================================================== ERROR: KASAN: use after free en notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Lectura de tama\u00f1o 8 en la direcci\u00f3n ffff88807324e2a8 por la tarea syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 No contaminado 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en l\u00ednea] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [en l\u00ednea] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [en l\u00ednea] llamar_notificadores_dispositivos_de_red net/core/dev.c:1997 [en l\u00ednea] netdev_wait_allrefs_any net/core/dev.c:10237 [en l\u00ednea] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [en l\u00ednea] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 tarea_trabajo_ejecutar+0x16f/0x270 kernel/tarea_trabajo.c:179 salir_tarea_trabajo incluir/linux/tarea_trabajo.h:38 [en l\u00ednea] hacer_salir+0xb3d/0x2a30 kernel/exit.c:820 hacer_grupo_salir+0xd4/0x2a0 kernel/exit.c:950 obtener_se\u00f1al+0x21b1/0x2440 kernel/se\u00f1al.c:2858 arch_hacer_se\u00f1al_o_reiniciar+0x86/0x2300 arch/x86/kernel/signal.c:869 bucle_salir_a_modo_usuario kernel/entry/common.c:168 [en l\u00ednea] preparar_salir_a_modo_usuario+0x15f/0x250 kernel/entry/common.c:203 __syscall_salir_a_modo_usuario_trabajo kernel/entry/common.c:285 [en l\u00ednea] syscall_salir_a_modo_usuario+0x1d/0x50 kernel/entry/common.c:296 La causa del problema es que sock_put() de __tun_detach() descarta el \u00faltimo recuento de referencias para struct net y luego notifier_call_chain() de netdev_state_change() accede a ese struct net. Este parche corrige el problema llamando a sock_put() desde tun_detach() despu\u00e9s de que se hayan realizado todos los accesos necesarios para struct net."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49015.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49015",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.787",
"lastModified": "2024-10-21T20:15:12.787",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hsr: Fix potential use-after-free\n\nThe skb is delivered to netif_rx() which may free it, after calling this,\ndereferencing skb may trigger use-after-free."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:hsr: Se corrige un posible use after free. El skb se entrega a netif_rx() que puede liberarlo; despu\u00e9s de llamarlo, desreferenciar skb puede desencadenar un use after free."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49016.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49016",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.840",
"lastModified": "2024-10-21T20:15:12.840",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mdiobus: fix unbalanced node reference count\n\nI got the following report while doing device(mscc-miim) load test\nwith CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:\n\n OF: ERROR: memory leak, expected refcount 1 instead of 2,\n of_node_get()/of_node_put() unbalanced - destroy cset entry:\n attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0\n\nIf the 'fwnode' is not an acpi node, the refcount is get in\nfwnode_mdiobus_phy_device_register(), but it has never been\nput when the device is freed in the normal path. So call\nfwnode_handle_put() in phy_device_release() to avoid leak.\n\nIf it's an acpi node, it has never been get, but it's put\nin the error path, so call fwnode_handle_get() before\nphy_device_register() to keep get/put operation balanced."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mdiobus: arregla el recuento de referencias de nodos desequilibrados Obtuve el siguiente informe mientras realizaba la prueba de carga del dispositivo (mscc-miim) con CONFIG_OF_UNITTEST y CONFIG_OF_DYNAMIC habilitados: OF: ERROR: p\u00e9rdida de memoria, se esperaba un recuento de referencias 1 en lugar de 2, of_node_get()/of_node_put() desequilibrado - destruye la entrada cset: adjuntar un nodo superpuesto /spi/soc@0/mdio@7107009c/ethernet-phy@0 Si el 'fwnode' no es un nodo acpi, el recuento de referencias se obtiene en fwnode_mdiobus_phy_device_register(), pero nunca se ha colocado cuando el dispositivo se libera en la ruta normal. Entonces llama a fwnode_handle_put() en phy_device_release() para evitar la p\u00e9rdida. Si es un nodo acpi, nunca se ha obtenido, pero se coloca en la ruta de error, por lo que se llama a fwnode_handle_get() antes de phy_device_register() para mantener equilibrada la operaci\u00f3n de obtenci\u00f3n/colocaci\u00f3n."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49017.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49017",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.910",
"lastModified": "2024-10-21T20:15:12.910",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: re-fetch skb cb after tipc_msg_validate\n\nAs the call trace shows, the original skb was freed in tipc_msg_validate(),\nand dereferencing the old skb cb would cause an use-after-free crash.\n\n BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]\n Call Trace:\n <IRQ>\n tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]\n tipc_crypto_rcv+0xd32/0x1ec0 [tipc]\n tipc_rcv+0x744/0x1150 [tipc]\n ...\n Allocated by task 47078:\n kmem_cache_alloc_node+0x158/0x4d0\n __alloc_skb+0x1c1/0x270\n tipc_buf_acquire+0x1e/0xe0 [tipc]\n tipc_msg_create+0x33/0x1c0 [tipc]\n tipc_link_build_proto_msg+0x38a/0x2100 [tipc]\n tipc_link_timeout+0x8b8/0xef0 [tipc]\n tipc_node_timeout+0x2a1/0x960 [tipc]\n call_timer_fn+0x2d/0x1c0\n ...\n Freed by task 47078:\n tipc_msg_validate+0x7b/0x440 [tipc]\n tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc]\n tipc_crypto_rcv+0xd32/0x1ec0 [tipc]\n tipc_rcv+0x744/0x1150 [tipc]\n\nThis patch fixes it by re-fetching the skb cb from the new allocated skb\nafter calling tipc_msg_validate()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: volver a obtener el skb cb despu\u00e9s de tipc_msg_validate Como muestra el seguimiento de la llamada, el skb original se liber\u00f3 en tipc_msg_validate(), y desreferenciar el antiguo skb cb causar\u00eda un bloqueo por use after free. ERROR: KASAN: use after free en tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] Seguimiento de llamadas: tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] ... Asignado por la tarea 47078: kmem_cache_alloc_node+0x158/0x4d0 __alloc_skb+0x1c1/0x270 tipc_buf_acquire+0x1e/0xe0 [tipc] tipc_msg_create+0x33/0x1c0 [tipc] tipc_link_build_proto_msg+0x38a/0x2100 [tipc] tipc_link_timeout+0x8b8/0xef0 [tipc] tipc_node_timeout+0x2a1/0x960 [tipc] call_timer_fn+0x2d/0x1c0 ... Liberado por la tarea 47078: tipc_msg_validate+0x7b/0x440 [tipc] tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] Este parche lo corrige volviendo a obtener el cb skb del nuevo skb asignado despu\u00e9s de llamar a tipc_msg_validate()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49018.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49018",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:12.973",
"lastModified": "2024-10-21T20:15:12.973",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix sleep in atomic at close time\n\nMatt reported a splat at msk close time:\n\n BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrill\n preempt_count: 201, expected: 0\n RCU nest depth: 0, expected: 0\n 4 locks held by packetdrill/155:\n #0: ffff888001536990 (&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release (net/socket.c:650)\n #1: ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close (net/mptcp/protocol.c:2973)\n #2: ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, at: __mptcp_close_ssk (net/mptcp/protocol.c:2363)\n #3: ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, at: __lock_sock_fast (include/net/sock.h:1820)\n Preemption disabled at:\n 0x0\n CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n Call Trace:\n <TASK>\n dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))\n __might_resched.cold (kernel/sched/core.c:9891)\n __mptcp_destroy_sock (include/linux/kernel.h:110)\n __mptcp_close (net/mptcp/protocol.c:2959)\n mptcp_subflow_queue_clean (include/net/sock.h:1777)\n __mptcp_close_ssk (net/mptcp/protocol.c:2363)\n mptcp_destroy_common (net/mptcp/protocol.c:3170)\n mptcp_destroy (include/net/sock.h:1495)\n __mptcp_destroy_sock (net/mptcp/protocol.c:2886)\n __mptcp_close (net/mptcp/protocol.c:2959)\n mptcp_close (net/mptcp/protocol.c:2974)\n inet_release (net/ipv4/af_inet.c:432)\n __sock_release (net/socket.c:651)\n sock_close (net/socket.c:1367)\n __fput (fs/file_table.c:320)\n task_work_run (kernel/task_work.c:181 (discriminator 1))\n exit_to_user_mode_prepare (include/linux/resume_user_mode.h:49)\n syscall_exit_to_user_mode (kernel/entry/common.c:130)\n do_syscall_64 (arch/x86/entry/common.c:87)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)\n\nWe can't call mptcp_close under the 'fast' socket lock variant, replace\nit with a sock_lock_nested() as the relevant code is already under the\nlistening msk socket lock protection."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: se corrige la suspensi\u00f3n en atomic en el momento del cierre Matt inform\u00f3 un splat en el momento del cierre de msk: ERROR: funci\u00f3n de suspensi\u00f3n llamada desde un contexto no v\u00e1lido en net/mptcp/protocol.c:2877 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrill preempt_count: 201, expected: 0 Profundidad de anidaci\u00f3n de RCU: 0, expected: 0 4 bloqueos mantenidos por packetdrill/155: #0: ffff888001536990 (&amp;sb-&gt;s_type-&gt;i_mutex_key#6){+.+.}-{3:3}, en: __sock_release (net/socket.c:650) #1: ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, en: mptcp_close (net/mptcp/protocol.c:2973) #2: ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, en: __mptcp_close_ssk (net/mptcp/protocol.c:2363) #3: ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, en: __lock_sock_fast (include/net/sock.h:1820) Preempci\u00f3n deshabilitada en: 0x0 CPU: 1 PID: 155 Comm: packetdrill No contaminado 6.1.0-rc5 #365 Nombre del hardware: QEMU PC est\u00e1ndar (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:107 (discriminador 4)) __might_resched.cold (kernel/sched/core.c:9891) __mptcp_destroy_sock (include/linux/kernel.h:110) __mptcp_close (net/mptcp/protocol.c:2959) mptcp_subflow_queue_clean (include/net/sock.h:1777) __mptcp_close_ssk (net/mptcp/protocol.c:2363) mptcp_destroy_common (net/mptcp/protocol.c:3170) mptcp_destroy (include/net/sock.h:1495) __mptcp_destroy_sock (net/mptcp/protocol.c:2886) __mptcp_close (net/mptcp/protocol.c:2959) mptcp_close (net/mptcp/protocol.c:2974) inet_release (net/ipv4/af_inet.c:432) __sock_release (net/socket.c:651) sock_close (net/socket.c:1367) __fput (fs/file_table.c:320) task_work_run (kernel/task_work.c:181 (discriminador 1)) salir_a_modo_usuario_preparar (include/linux/reanudar_modo_usuario.h:49) No podemos llamar a mptcp_close bajo la variante de bloqueo de socket 'r\u00e1pido', reempl\u00e1celo con sock_lock_nested() ya que el c\u00f3digo relevante ya est\u00e1 bajo la protecci\u00f3n de bloqueo de socket msk de escucha."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49019.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49019",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.040",
"lastModified": "2024-10-21T20:15:13.040",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: nixge: fix NULL dereference\n\nIn function nixge_hw_dma_bd_release() dereference of NULL pointer\npriv->rx_bd_v is possible for the case of its allocation failure in\nnixge_hw_dma_bd_init().\n\nMove for() loop with priv->rx_bd_v dereference under the check for\nits validity.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: nixge: fix NULL dereference En la funci\u00f3n nixge_hw_dma_bd_release(), es posible desreferenciar el puntero NULL priv-&gt;rx_bd_v en caso de que falle su asignaci\u00f3n en nixge_hw_dma_bd_init(). Mueva el bucle for() con la desreferencia priv-&gt;rx_bd_v bajo la verificaci\u00f3n de su validez. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49020.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49020",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.100",
"lastModified": "2024-10-21T20:15:13.100",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/9p: Fix a potential socket leak in p9_socket_open\n\nBoth p9_fd_create_tcp() and p9_fd_create_unix() will call\np9_socket_open(). If the creation of p9_trans_fd fails,\np9_fd_create_tcp() and p9_fd_create_unix() will return an\nerror directly instead of releasing the cscoket, which will\nresult in a socket leak.\n\nThis patch adds sock_release() to fix the leak issue."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/9p: Se soluciona una posible fuga de socket en p9_socket_open Tanto p9_fd_create_tcp() como p9_fd_create_unix() llamar\u00e1n a p9_socket_open(). Si la creaci\u00f3n de p9_trans_fd fallo, p9_fd_create_tcp() y p9_fd_create_unix() devolver\u00e1n un error directamente en lugar de liberar el cscoket, lo que provocar\u00e1 una fuga de socket. Este parche agrega sock_release() para solucionar el problema de la fuga."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49021.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49021",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.163",
"lastModified": "2024-10-21T20:15:13.163",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: fix null-ptr-deref while probe() failed\n\nI got a null-ptr-deref report as following when doing fault injection test:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000058\nOops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:klist_put+0x2d/0xd0\nCall Trace:\n <TASK>\n klist_remove+0xf1/0x1c0\n device_release_driver_internal+0x23e/0x2d0\n bus_remove_device+0x1bd/0x240\n device_del+0x357/0x770\n phy_device_remove+0x11/0x30\n mdiobus_unregister+0xa5/0x140\n release_nodes+0x6a/0xa0\n devres_release_all+0xf8/0x150\n device_unbind_cleanup+0x19/0xd0\n\n//probe path:\nphy_device_register()\n device_add()\n\nphy_connect\n phy_attach_direct() //set device driver\n probe() //it's failed, driver is not bound\n device_bind_driver() // probe failed, it's not called\n\n//remove path:\nphy_device_remove()\n device_del()\n device_release_driver_internal()\n __device_release_driver() //dev->drv is not NULL\n klist_remove() <- knode_driver is not added yet, cause null-ptr-deref\n\nIn phy_attach_direct(), after setting the 'dev->driver', probe() fails,\ndevice_bind_driver() is not called, so the knode_driver->n_klist is not\nset, then it causes null-ptr-deref in __device_release_driver() while\ndeleting device. Fix this by setting dev->driver to NULL in the error\npath in phy_attach_direct()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: fix null-ptr-deref while probe() failed Obtuve un informe null-ptr-deref como el siguiente al realizar la prueba de inyecci\u00f3n de fallos: ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 0000000000000058 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: GBN 6.1.0-rc3+ Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:klist_put+0x2d/0xd0 Rastreo de llamadas: klist_remove+0xf1/0x1c0 device_release_driver_internal+0x23e/0x2d0 bus_remove_device+0x1bd/0x240 device_del+0x357/0x770 phy_device_remove+0x11/0x30 mdiobus_unregister+0xa5/0x140 release_nodes+0x6a/0xa0 devres_release_all+0xf8/0x150 device_unbind_cleanup+0x19/0xd0 //ruta de la sonda: phy_device_register() device_add() phy_connect phy_attach_direct() //establecer el controlador del dispositivo probe() //ha fallodo, el controlador no est\u00e1 vinculado device_bind_driver() //la sonda ha fallodo, no se llama //ruta de eliminaci\u00f3n: phy_device_remove() device_del() device_release_driver_internal() __device_release_driver() //dev-&gt;drv no es NULL klist_remove() &lt;- knode_driver a\u00fan no se agreg\u00f3, causa null-ptr-deref En phy_attach_direct(), despu\u00e9s de configurar 'dev-&gt;driver', probe() fallo, device_bind_driver() no se llama, por lo que knode_driver-&gt;n_klist no est\u00e1 configurado, luego causa null-ptr-deref en __device_release_driver() mientras se elimina el dispositivo. Solucione esto configurando dev-&gt;driver en NULL en la ruta de error en phy_attach_direct()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49022.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49022",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.233",
"lastModified": "2024-10-21T20:15:13.233",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac8021: fix possible oob access in ieee80211_get_rate_duration\n\nFix possible out-of-bound access in ieee80211_get_rate_duration routine\nas reported by the following UBSAN report:\n\nUBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47\nindex 15 is out of range for type 'u16 [12]'\nCPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic\nHardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017\nWorkqueue: mt76 mt76u_tx_status_data [mt76_usb]\nCall Trace:\n <TASK>\n show_stack+0x4e/0x61\n dump_stack_lvl+0x4a/0x6f\n dump_stack+0x10/0x18\n ubsan_epilogue+0x9/0x43\n __ubsan_handle_out_of_bounds.cold+0x42/0x47\nieee80211_get_rate_duration.constprop.0+0x22f/0x2a0 [mac80211]\n ? ieee80211_tx_status_ext+0x32e/0x640 [mac80211]\n ieee80211_calc_rx_airtime+0xda/0x120 [mac80211]\n ieee80211_calc_tx_airtime+0xb4/0x100 [mac80211]\n mt76x02_send_tx_status+0x266/0x480 [mt76x02_lib]\n mt76x02_tx_status_data+0x52/0x80 [mt76x02_lib]\n mt76u_tx_status_data+0x67/0xd0 [mt76_usb]\n process_one_work+0x225/0x400\n worker_thread+0x50/0x3e0\n ? process_one_work+0x400/0x400\n kthread+0xe9/0x110\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x22/0x30"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac8021: se corrige un posible acceso fuera de los l\u00edmites en ieee80211_get_rate_duration Se corrige un posible acceso fuera de los l\u00edmites en la rutina ieee80211_get_rate_duration seg\u00fan lo informado por el siguiente informe de UBSAN: UBSAN: array-index-out-of-bounds en net/mac80211/airtime.c:455:47 el \u00edndice 15 est\u00e1 fuera de rango para el tipo 'u16 [12]' CPU: 2 PID: 217 Comm: kworker/u32:10 No contaminado 6.1.0-060100rc3-generic Nombre del hardware: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 18/07/2017 Cola de trabajo: mt76 mt76u_tx_status_data [mt76_usb] Seguimiento de llamadas: show_stack+0x4e/0x61 dump_stack_lvl+0x4a/0x6f dump_stack+0x10/0x18 ubsan_epilogue+0x9/0x43 __ubsan_handle_out_of_bounds.cold+0x42/0x47 ieee80211_get_rate_duration.constprop.0+0x22f/0x2a0 [mac80211] ? ieee80211_tx_status_ext+0x32e/0x640 [mac80211] ieee80211_calc_rx_airtime+0xda/0x120 [mac80211] ieee80211_calc_tx_airtime+0xb4/0x100 [mac80211] mt76x02_send_tx_status+0x266/0x480 [mt76x02_lib] mt76x02_tx_status_data+0x52/0x80 [mt76x02_lib] mt76u_tx_status_data+0x67/0xd0 [mt76_usb] proceso_uno_trabajo+0x225/0x400 subproceso_de_trabajo+0x50/0x3e0 ? proceso_uno_trabajo+0x400/0x400 subproceso_k+0xe9/0x110 ? subproceso_k_completo_y_salida+0x20/0x20 ret_de_la_bifurcaci\u00f3n+0x22/0x30"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49023.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49023",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.290",
"lastModified": "2024-10-21T20:15:13.290",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: fix buffer overflow in elem comparison\n\nFor vendor elements, the code here assumes that 5 octets\nare present without checking. Since the element itself is\nalready checked to fit, we only need to check the length."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: se corrige el desbordamiento de b\u00fafer en la comparaci\u00f3n de elementos. Para los elementos del proveedor, el c\u00f3digo aqu\u00ed supone que hay 5 octetos presentes sin verificaci\u00f3n. Dado que el elemento en s\u00ed ya est\u00e1 verificado para que encaje, solo necesitamos verificar la longitud."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49024.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49024",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.367",
"lastModified": "2024-10-21T20:15:13.367",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods\n\nIn m_can_pci_remove() and error handling path of m_can_pci_probe(),\nm_can_class_free_dev() should be called to free resource allocated by\nm_can_class_allocate_dev(), otherwise there will be memleak."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: m_can: pci: agregar m_can_class_free_dev() faltante en los m\u00e9todos probe/remove En m_can_pci_remove() y la ruta de manejo de errores de m_can_pci_probe(), se debe llamar a m_can_class_free_dev() para liberar el recurso asignado por m_can_class_allocate_dev(), de lo contrario habr\u00e1 una fuga de memoria."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49025.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49025",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.427",
"lastModified": "2024-10-21T20:15:13.427",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix use-after-free when reverting termination table\n\nWhen having multiple dests with termination tables and second one\nor afterwards fails the driver reverts usage of term tables but\ndoesn't reset the assignment in attr->dests[num_vport_dests].termtbl\nwhich case a use-after-free when releasing the rule.\nFix by resetting the assignment of termtbl to null."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Se corrige el use after free al revertir la tabla de terminaci\u00f3n Cuando se tienen varios destinos con tablas de terminaci\u00f3n y fallo el segundo o posteriores, el controlador revierte el uso de las tablas de t\u00e9rminos, pero no restablece la asignaci\u00f3n en attr-&gt;dests[num_vport_dests].termtbl, en cuyo caso se produce un use after free al liberar la regla. Se soluciona restableciendo la asignaci\u00f3n de termtbl a nulo."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49026.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49026",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.490",
"lastModified": "2024-10-21T20:15:13.490",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ne100: Fix possible use after free in e100_xmit_prepare\n\nIn e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so\ne100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will\nresend the skb. But the skb is already freed, which will cause UAF bug\nwhen the upper layer resends the skb.\n\nRemove the harmful free."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: e100: Se corrige el posible use after free en e100_xmit_prepare En e100_xmit_prepare(), si no podemos mapear el skb, entonces devolvemos -ENOMEM, por lo que e100_xmit_frame() devolver\u00e1 NETDEV_TX_BUSY y la capa superior reenviar\u00e1 el skb. Pero el skb ya est\u00e1 liberado, lo que provocar\u00e1 un error UAF cuando la capa superior reenv\u00ede el skb. Elimine la liberaci\u00f3n da\u00f1ina."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49027.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49027",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.563",
"lastModified": "2024-10-21T20:15:13.563",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: Fix error handling in iavf_init_module()\n\nThe iavf_init_module() won't destroy workqueue when pci_register_driver()\nfailed. Call destroy_workqueue() when pci_register_driver() failed to\nprevent the resource leak.\n\nSimilar to the handling of u132_hcd_init in commit f276e002793c\n(\"usb: u132-hcd: fix resource leak\")"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: Se ha corregido el manejo de errores en iavf_init_module(). iavf_init_module() no destruir\u00e1 workqueue cuando falle pci_register_driver(). Se llama a destroy_workqueue() cuando falle pci_register_driver() para evitar la p\u00e9rdida de recursos. Similar al manejo de u132_hcd_init en el commit f276e002793c (\"usb: u132-hcd: fix resource leak\")"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49028.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49028",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.627",
"lastModified": "2024-10-21T20:15:13.627",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: Fix resource leak in ixgbevf_init_module()\n\nixgbevf_init_module() won't destroy the workqueue created by\ncreate_singlethread_workqueue() when pci_register_driver() failed. Add\ndestroy_workqueue() in fail path to prevent the resource leak.\n\nSimilar to the handling of u132_hcd_init in commit f276e002793c\n(\"usb: u132-hcd: fix resource leak\")"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ixgbevf: Se solucion\u00f3 la p\u00e9rdida de recursos en ixgbevf_init_module() ixgbevf_init_module() no destruir\u00e1 la cola de trabajo creada por create_singlethread_workqueue() cuando pci_register_driver() fall\u00f3. Agregue destroy_workqueue() en la ruta de error para evitar la p\u00e9rdida de recursos. Similar al manejo de u132_hcd_init en el commit f276e002793c (\"usb: u132-hcd: fix resource leak\")"
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49029.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49029",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.690",
"lastModified": "2024-10-21T20:15:13.690",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails\n\nSmatch report warning as follows:\n\ndrivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn:\n '&data->list' not removed from list\n\nIf ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will\nbe freed, but data->list will not be removed from driver_data.bmc_data,\nthen list traversal may cause UAF.\n\nFix by removeing it from driver_data.bmc_data before free()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (ibmpex) Se corrige un posible UAF cuando fallo ibmpex_register_bmc() Advertencia de informe de Smatch de la siguiente manera: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&amp;data-&gt;list' no se elimin\u00f3 de la lista Si ibmpex_find_sensors() fallo en ibmpex_register_bmc(), se liberar\u00e1n los datos, pero data-&gt;list no se eliminar\u00e1 de driver_data.bmc_data, entonces el recorrido de la lista puede causar UAF. Se soluciona elimin\u00e1ndolo de driver_data.bmc_data antes de free()."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49030.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49030",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.747",
"lastModified": "2024-10-21T20:15:13.747",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nlibbpf: Handle size overflow for ringbuf mmap\n\nThe maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries\nwill overflow u32 when mapping producer page and data pages. Only\ncasting max_entries to size_t is not enough, because for 32-bits\napplication on 64-bits kernel the size of read-only mmap region\nalso could overflow size_t.\n\nSo fixing it by casting the size of read-only mmap region into a __u64\nand checking whether or not there will be overflow during mmap."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: libbpf: desbordamiento de tama\u00f1o del controlador para ringbuf mmap El tama\u00f1o m\u00e1ximo de ringbuf es de 2 GB en un host x86-64, por lo que 2 * max_entries desbordar\u00e1n u32 al asignar la p\u00e1gina del productor y las p\u00e1ginas de datos. Solo convertir max_entries a size_t no es suficiente, porque para la aplicaci\u00f3n de 32 bits en un kernel de 64 bits, el tama\u00f1o de la regi\u00f3n mmap de solo lectura tambi\u00e9n podr\u00eda desbordar size_t. Entonces, arr\u00e9glelo convirtiendo el tama\u00f1o de la regi\u00f3n mmap de solo lectura en __u64 y verificando si habr\u00e1 o no desbordamiento durante mmap."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49031.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49031",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.807",
"lastModified": "2024-10-21T20:15:13.807",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: health: afe4403: Fix oob read in afe4403_read_raw\n\nKASAN report out-of-bounds read as follows:\n\nBUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0\nRead of size 4 at addr ffffffffc02ac638 by task cat/279\n\nCall Trace:\n afe4403_read_raw\n iio_read_channel_info\n dev_attr_show\n\nThe buggy address belongs to the variable:\n afe4403_channel_leds+0x18/0xffffffffffffe9e0\n\nThis issue can be reproduced by singe command:\n\n $ cat /sys/bus/spi/devices/spi0.0/iio\\:device0/in_intensity6_raw\n\nThe array size of afe4403_channel_leds is less than channels, so access\nwith chan->address cause OOB read in afe4403_read_raw. Fix it by moving\naccess before use it."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: health: afe4403: Se corrige la lectura oob en el informe de KASAN afe4403_read_raw que indica que la lectura est\u00e1 fuera de los l\u00edmites de la siguiente manera: ERROR: KASAN: global-out-of-bounds en afe4403_read_raw+0x42e/0x4c0 Lectura de tama\u00f1o 4 en la direcci\u00f3n ffffffffc02ac638 por la tarea cat/279 Seguimiento de llamadas: afe4403_read_raw iio_read_channel_info dev_attr_show La direcci\u00f3n con errores pertenece a la variable: afe4403_channel_leds+0x18/0xffffffffffffe9e0 Este problema se puede reproducir con un solo comando: $ cat /sys/bus/spi/devices/spi0.0/iio\\:device0/in_intensity6_raw El tama\u00f1o de la matriz de afe4403_channel_leds es menor que channels, por lo que el acceso con chan-&gt;address provoca una lectura OOB en afe4403_read_raw. Solucione el problema moviendo el acceso antes de usarlo."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49032.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49032",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.877",
"lastModified": "2024-10-21T20:15:13.877",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: health: afe4404: Fix oob read in afe4404_[read|write]_raw\n\nKASAN report out-of-bounds read as follows:\n\nBUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380\nRead of size 4 at addr ffffffffc00e4658 by task cat/278\n\nCall Trace:\n afe4404_read_raw\n iio_read_channel_info\n dev_attr_show\n\nThe buggy address belongs to the variable:\n afe4404_channel_leds+0x18/0xffffffffffffe9c0\n\nThis issue can be reproduce by singe command:\n\n $ cat /sys/bus/i2c/devices/0-0058/iio\\:device0/in_intensity6_raw\n\nThe array size of afe4404_channel_leds and afe4404_channel_offdacs\nare less than channels, so access with chan->address cause OOB read\nin afe4404_[read|write]_raw. Fix it by moving access before use them."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: health: afe4404: Se corrige la lectura oob en el informe de KASAN afe4404_[read|write]_raw de la siguiente manera: ERROR: KASAN: global-out-of-bounds en afe4404_read_raw+0x2ce/0x380 Lectura de tama\u00f1o 4 en la direcci\u00f3n ffffffffc00e4658 por la tarea cat/278 Rastreo de llamadas: afe4404_read_raw iio_read_channel_info dev_attr_show La direcci\u00f3n con errores pertenece a la variable: afe4404_channel_leds+0x18/0xffffffffffffe9c0 Este problema se puede reproducir con un solo comando: $ cat /sys/bus/i2c/devices/0-0058/iio\\:device0/in_intensity6_raw El tama\u00f1o de la matriz de afe4404_channel_leds y afe4404_channel_offdacs son menores que los canales, por lo que el acceso con chan-&gt;address provoca una lectura OOB en afe4404_[read|write]_raw. Solucione este problema moviendo el acceso antes de usarlos."
}
],
"metrics": {},

8
CVE-2022/CVE-2022-490xx/CVE-2022-49033.json
View File

@ -2,13 +2,17 @@
"id": "CVE-2022-49033",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-10-21T20:15:13.943",
"lastModified": "2024-10-21T20:15:13.943",
"vulnStatus": "Received",
"lastModified": "2024-10-23T15:12:34.673",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()\n\nSyzkaller reported BUG as follows:\n\n BUG: sleeping function called from invalid context at\n include/linux/sched/mm.h:274\n Call Trace:\n <TASK>\n dump_stack_lvl+0xcd/0x134\n __might_resched.cold+0x222/0x26b\n kmem_cache_alloc+0x2e7/0x3c0\n update_qgroup_limit_item+0xe1/0x390\n btrfs_qgroup_inherit+0x147b/0x1ee0\n create_subvol+0x4eb/0x1710\n btrfs_mksubvol+0xfe5/0x13f0\n __btrfs_ioctl_snap_create+0x2b0/0x430\n btrfs_ioctl_snap_create_v2+0x25a/0x520\n btrfs_ioctl+0x2a1c/0x5ce0\n __x64_sys_ioctl+0x193/0x200\n do_syscall_64+0x35/0x80\n\nFix this by calling qgroup_dirty() on @dstqgroup, and update limit item in\nbtrfs_run_qgroups() later outside of the spinlock context."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: qgroup: correcci\u00f3n del error de suspensi\u00f3n desde un contexto no v\u00e1lido en btrfs_qgroup_inherit() Syzkaller inform\u00f3 de un ERROR como el siguiente: ERROR: funci\u00f3n de suspensi\u00f3n llamada desde un contexto no v\u00e1lido en include/linux/sched/mm.h:274 Seguimiento de llamadas: dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Solucione esto llamando a qgroup_dirty() en @dstqgroup y actualice el elemento de l\u00edmite en btrfs_run_qgroups() m\u00e1s tarde fuera del contexto de spinlock."
}
],
"metrics": {},

34
CVE-2023/CVE-2023-206xx/CVE-2023-20677.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2023-20677",
"sourceIdentifier": "security@mediatek.com",
"published": "2023-04-06T18:15:09.357",
"lastModified": "2023-04-12T19:41:24.083",
"vulnStatus": "Analyzed",
"lastModified": "2024-10-23T15:35:08.200",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
{
@ -32,6 +32,26 @@
},
"exploitabilityScore": 0.8,
"impactScore": 3.6
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"attackVector": "LOCAL",
"attackComplexity": "LOW",
"privilegesRequired": "HIGH",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"availabilityImpact": "NONE",
"baseScore": 4.4,
"baseSeverity": "MEDIUM"
},
"exploitabilityScore": 0.8,
"impactScore": 3.6
}
]
},
@ -45,6 +65,16 @@
"value": "CWE-125"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-125"
}
]
}
],
"configurations": [

22
CVE-2023/CVE-2023-262xx/CVE-2023-26269.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2023-26269",
"sourceIdentifier": "security@apache.org",
"published": "2023-04-03T08:15:07.087",
"lastModified": "2023-04-18T03:15:07.593",
"lastModified": "2024-10-23T15:35:10.417",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
@ -32,6 +32,26 @@
},
"exploitabilityScore": 1.8,
"impactScore": 5.9
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"attackVector": "LOCAL",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9
}
]
},

24
CVE-2023/CVE-2023-287xx/CVE-2023-28707.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2023-28707",
"sourceIdentifier": "security@apache.org",
"published": "2023-04-07T15:15:08.067",
"lastModified": "2023-05-22T14:25:13.693",
"vulnStatus": "Analyzed",
"lastModified": "2024-10-23T15:35:10.927",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
{
@ -32,6 +32,26 @@
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"availabilityImpact": "NONE",
"baseScore": 7.5,
"baseSeverity": "HIGH"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
}
]
},

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