mirror of
https://github.com/fkie-cad/nvd-json-data-feeds.git
synced 2025-06-21 17:41:05 +00:00
Auto-Update: 2024-05-26T02:00:29.531128+00:00
This commit is contained in:
cad-safe-bot
parent
1114194849
commit
727f7e284a
@ -3,7 +3,7 @@
|
||||
"sourceIdentifier": "security@apache.org",
|
||||
"published": "2021-01-05T12:15:12.680",
|
||||
"lastModified": "2024-05-23T19:54:02.487",
|
||||
"vulnStatus": "Modified",
|
||||
"vulnStatus": "Undergoing Analysis",
|
||||
"cisaExploitAdd": "2024-05-23",
|
||||
"cisaActionDue": "2024-06-13",
|
||||
"cisaRequiredAction": "Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.",
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "Dell BSAFE Crypto-C Micro Edition, versions before 4.1.5, and Dell BSAFE Micro Edition Suite, versions before 4.6, contain an Observable Timing Discrepancy Vulnerability."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "Dell BSAFE Crypto-C Micro Edition, versiones anteriores a 4.1.5, y Dell BSAFE Micro Edition Suite, versiones anteriores a 4.6, contienen una vulnerabilidad de discrepancia de tiempo observable."
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: avoid a use-after-free when BO init fails\n\nnouveau_bo_init() is backed by ttm_bo_init() and ferries its return code\nback to the caller. On failures, ttm_bo_init() invokes the provided\ndestructor which should de-initialize and free the memory.\n\nThus, when nouveau_bo_init() returns an error the gem object has already\nbeen released and the memory freed by nouveau_bo_del_ttm()."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: evita un use after free cuando falla BO init nouveau_bo_init() est\u00e1 respaldado por ttm_bo_init() y env\u00eda su c\u00f3digo de retorno de regreso a la persona que llama. En caso de falla, ttm_bo_init() invoca el destructor proporcionado que deber\u00eda desinicializar y liberar la memoria. Por lo tanto, cuando nouveau_bo_init() devuelve un error, el objeto gema ya ha sido liberado y la memoria ha sido liberada por nouveau_bo_del_ttm()."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "A potential vulnerability has been identified for OpenText Operations Bridge Reporter. The vulnerability could be exploited to inject malicious SQL queries. An attack requires to be an authenticated administrator of OBR with network access to the OBR web application."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "Se ha identificado una vulnerabilidad potencial para OpenText Operations Bridge Reporter. La vulnerabilidad podr\u00eda explotarse para inyectar consultas SQL maliciosas. Un ataque requiere ser un administrador autenticado de OBR con acceso de red a la aplicaci\u00f3n web de OBR."
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "Improper input validation in some Intel(R) Ethernet Adapters and Intel(R) Ethernet Controller I225 Manageability firmware may allow an unauthenticated user to potentially enable denial of service via network access."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "La validaci\u00f3n de entrada incorrecta en algunos adaptadores Intel(R) Ethernet y en el firmware de capacidad de administraci\u00f3n del controlador Intel(R) Ethernet I225 puede permitir que un usuario no autenticado habilite potencialmente la denegaci\u00f3n de servicio a trav\u00e9s del acceso a la red."
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "Improper input validation in some Intel(R) Ethernet Adapters and Intel(R) Ethernet Controller I225 Manageability firmware may allow a privileged user to potentially enable denial of service via local access."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "La validaci\u00f3n de entrada incorrecta en algunos adaptadores Intel(R) Ethernet y en el firmware de capacidad de administraci\u00f3n del controlador Intel(R) Ethernet I225 puede permitir que un usuario privilegiado habilite potencialmente la denegaci\u00f3n de servicio a trav\u00e9s del acceso local."
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "Uncaught exception in some Intel(R) Ethernet Adapters and Intel(R) Ethernet Controller I225 Manageability firmware may allow a privileged user to potentially enable escalation of privilege via local access."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "Una excepci\u00f3n no detectada en algunos adaptadores Intel(R) Ethernet y en el firmware de capacidad de administraci\u00f3n del controlador Intel(R) Ethernet I225 puede permitir que un usuario privilegiado habilite potencialmente la escalada de privilegios a trav\u00e9s del acceso local."
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "Improper input validation in some Intel(R) Ethernet Adapters and Intel(R) Ethernet Controller I225 Manageability firmware may allow an unauthenticated user to potentially enable information disclosure via network access."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "La validaci\u00f3n de entrada incorrecta en algunos adaptadores Intel(R) Ethernet y en el firmware de capacidad de administraci\u00f3n del controlador Intel(R) Ethernet I225 puede permitir que un usuario no autenticado habilite potencialmente la divulgaci\u00f3n de informaci\u00f3n a trav\u00e9s del acceso a la red."
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "Insufficient control flow management in some Intel(R) Ethernet Adapters and Intel(R) Ethernet Controller I225 Manageability firmware may allow a privileged user to potentially enable escalation of privilege via local access."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "La gesti\u00f3n insuficiente del flujo de control en algunos adaptadores Intel(R) Ethernet y en el firmware de capacidad de administraci\u00f3n del controlador Intel(R) Ethernet I225 puede permitir que un usuario privilegiado habilite potencialmente la escalada de privilegios a trav\u00e9s del acceso local."
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "Improper neutralization in some Intel(R) Ethernet Adapters and Intel(R) Ethernet Controller I225 Manageability firmware may allow a privileged user to potentially enable escalation of privilege via local access."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "La neutralizaci\u00f3n inadecuada en algunos adaptadores Intel(R) Ethernet y en el firmware de capacidad de administraci\u00f3n del controlador Intel(R) Ethernet I225 puede permitir que un usuario privilegiado habilite potencialmente la escalada de privilegios a trav\u00e9s del acceso local."
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "Improper input validation in some Intel(R) Ethernet Adapters and Intel(R) Ethernet Controller I225 Manageability firmware may allow a privileged user to potentially enable escalation of privilege via local access."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "La validaci\u00f3n de entrada incorrecta en algunos adaptadores Intel(R) Ethernet y en el firmware de capacidad de administraci\u00f3n del controlador Intel(R) Ethernet I225 puede permitir que un usuario privilegiado habilite potencialmente la escalada de privilegios a trav\u00e9s del acceso local."
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "Improper access control in some Intel(R) Ethernet Adapters and Intel(R) Ethernet Controller I225 Manageability firmware may allow an authenticated user to potentially enable escalation of privilege via local access."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "Un control de acceso inadecuado en algunos adaptadores Intel(R) Ethernet y en el firmware de capacidad de administraci\u00f3n del controlador Intel(R) Ethernet I225 puede permitir que un usuario autenticado habilite potencialmente la escalada de privilegios a trav\u00e9s del acceso local."
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
"sourceIdentifier": "secalert@redhat.com",
|
||||
"published": "2021-06-02T13:15:13.170",
|
||||
"lastModified": "2024-03-27T16:12:07.343",
|
||||
"vulnStatus": "Analyzed",
|
||||
"vulnStatus": "Undergoing Analysis",
|
||||
"descriptions": [
|
||||
{
|
||||
"lang": "en",
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: core: fix kernel panic when do reboot\n\nWhen do system reboot, it calls dwc3_shutdown and the whole debugfs\nfor dwc3 has removed first, when the gadget tries to do deinit, and\nremove debugfs for its endpoints, it meets NULL pointer dereference\nissue when call debugfs_lookup. Fix it by removing the whole dwc3\ndebugfs later than dwc3_drd_exit.\n\n[ 2924.958838] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000002\n....\n[ 2925.030994] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)\n[ 2925.037005] pc : inode_permission+0x2c/0x198\n[ 2925.041281] lr : lookup_one_len_common+0xb0/0xf8\n[ 2925.045903] sp : ffff80001276ba70\n[ 2925.049218] x29: ffff80001276ba70 x28: ffff0000c01f0000 x27: 0000000000000000\n[ 2925.056364] x26: ffff800011791e70 x25: 0000000000000008 x24: dead000000000100\n[ 2925.063510] x23: dead000000000122 x22: 0000000000000000 x21: 0000000000000001\n[ 2925.070652] x20: ffff8000122c6188 x19: 0000000000000000 x18: 0000000000000000\n[ 2925.077797] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000004\n[ 2925.084943] x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000030\n[ 2925.092087] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : ffff8000102b2420\n[ 2925.099232] x8 : 7f7f7f7f7f7f7f7f x7 : feff73746e2f6f64 x6 : 0000000000008080\n[ 2925.106378] x5 : 61c8864680b583eb x4 : 209e6ec2d263dbb7 x3 : 000074756f307065\n[ 2925.113523] x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff8000122c6188\n[ 2925.120671] Call trace:\n[ 2925.123119] inode_permission+0x2c/0x198\n[ 2925.127042] lookup_one_len_common+0xb0/0xf8\n[ 2925.131315] lookup_one_len_unlocked+0x34/0xb0\n[ 2925.135764] lookup_positive_unlocked+0x14/0x50\n[ 2925.140296] debugfs_lookup+0x68/0xa0\n[ 2925.143964] dwc3_gadget_free_endpoints+0x84/0xb0\n[ 2925.148675] dwc3_gadget_exit+0x28/0x78\n[ 2925.152518] dwc3_drd_exit+0x100/0x1f8\n[ 2925.156267] dwc3_remove+0x11c/0x120\n[ 2925.159851] dwc3_shutdown+0x14/0x20\n[ 2925.163432] platform_shutdown+0x28/0x38\n[ 2925.167360] device_shutdown+0x15c/0x378\n[ 2925.171291] kernel_restart_prepare+0x3c/0x48\n[ 2925.175650] kernel_restart+0x1c/0x68\n[ 2925.179316] __do_sys_reboot+0x218/0x240\n[ 2925.183247] __arm64_sys_reboot+0x28/0x30\n[ 2925.187262] invoke_syscall+0x48/0x100\n[ 2925.191017] el0_svc_common.constprop.0+0x48/0xc8\n[ 2925.195726] do_el0_svc+0x28/0x88\n[ 2925.199045] el0_svc+0x20/0x30\n[ 2925.202104] el0_sync_handler+0xa8/0xb0\n[ 2925.205942] el0_sync+0x148/0x180\n[ 2925.209270] Code: a9025bf5 2a0203f5 121f0056 370802b5 (79400660)\n[ 2925.215372] ---[ end trace 124254d8e485a58b ]---\n[ 2925.220012] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\n[ 2925.227676] Kernel Offset: disabled\n[ 2925.231164] CPU features: 0x00001001,20000846\n[ 2925.235521] Memory Limit: none\n[ 2925.238580] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---\n\n(cherry picked from commit 2a042767814bd0edf2619f06fecd374e266ea068)"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: usb: dwc3: core: soluciona el p\u00e1nico del kernel cuando se reinicia. Cuando se reinicia el sistema, llama a dwc3_shutdown y todos los debugfs para dwc3 se eliminan primero, cuando el dispositivo intenta realizar deinit. y elimina debugfs para sus endpoints, se encuentra con el problema de desreferencia del puntero NULL cuando se llama a debugfs_lookup. Solucionelo eliminando todos los debugfs de dwc3 posteriores a dwc3_drd_exit. [2924.958838] No se puede manejar la desreferencia del puntero NULL del kernel en la direcci\u00f3n virtual 0000000000000002 .... [2925.030994] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [2925.037005] pc: inode_permission+0x2c /0x198 [ 2925.041281 ] lr: lookup_one_len_common+0xb0/0xf8 [2925.045903] sp: ffff80001276ba70 [2925.049218] x29: ffff80001276ba70 x28: ffff0000c01f0000 x27: 0000000000000 000 [2925.056364] x26: ffff800011791e70 x25: 0000000000000008 x24: muerto000000000100 [2925.063510] x23: muerto000000000122 x22: 00000000000000 00x21: 0000000000000001 [ 2925.070652] x20: ffff8000122c6188 x19: 0000000000000000 x18: 0000000000000000 [ 2925.077797] x17: 0000000000000000 x16: 00000000 x15: 0000000000000004 [ 2925.084943] x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000030 [ 2925.092087] x11: 101010101 x10: 7f7f7f7f7f7f7f7f x9: ffff8000102b2420 [2925.099232 ] x8: 7f7f7f7f7f7f7f7f x7: feff73746e2f6f64 x6: 0000000000008080 [2925.106378] x5: 61c8864680b583eb x4: 209e6ec2d263dbb7 x3: 000074756 f307065 [2925.113523] x2: 0000000000000001 x1: 0000000000000000 x0: ffff8000122c6188 [2925.120671] Seguimiento de llamada: [2925.123119] inode_permission+0x2c/0x 198 [ 2925.127042 ] lookup_one_len_common+0xb0/0xf8 [ 2925.131315] lookup_one_len_unlocked+0x34/0xb0 [ 2925.135764] lookup_positive_unlocked+0x14/0x50 [ 2925.140296] debugfs_lookup+0x68/0xa0 [ 292 5.143964] dwc3_gadget_free_endpoints+0x84/0xb0 [ 2925.148675] dwc3_gadget_exit+0x28/0x78 [ 2925.152518] dwc3_drd_exit +0x100/0x1f8 [ 2925.156267] dwc3_remove+0x11c/0x120 [ 2925.159851] dwc3_shutdown+0x14/0x20 [ 2925.163432] platform_shutdown+0x28/0x38 [ 2925.167360] apagado+0x15c/0x378 [ 2925.171291] kernel_restart_prepare+0x3c/0x48 [ 2925.175650] kernel_restart+0x1c /0x68 [ 2925.179316] __do_sys_reboot+0x218/0x240 [ 2925.183247] __arm64_sys_reboot+0x28/0x30 [ 2925.187262] invoke_syscall+0x48/0x100 [ 2925.191017 ] el0_svc_common.constprop.0+0x48/0xc8 [ 2925.195726] do_el0_svc+0x28/0x88 [ 2925.199045] el0_svc +0x20/0x30 [ 2925.202104] el0_sync_handler+0xa8/0xb0 [ 2925.205942] el0_sync+0x148/0x180 [ 2925.209270] C\u00f3digo: a9025bf5 2a0203f5 121f0056 370802b5 9400660) [ 2925.215372] ---[ rastreo final 124254d8e485a58b ]--- [ 2925.220012] N\u00facleo p\u00e1nico - no se sincroniza: \u00a1Intent\u00e9 matar init! ExitCode = 0x0000000b [2925.227676] Offset del n\u00facleo: deshabilitado [2925.231164] Caracter\u00edsticas de la CPU: 0x00001001,20000846 [2925.235521] L\u00edmite de memoria: Ninguno [2925.238580] --- [final de Kernel Panic -No Syncing: Intento de matar init! c\u00f3digo de salida=0x0000000b ]--- (seleccionado del compromiso 2a042767814bd0edf2619f06fecd374e266ea068)"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: actually fix freelist pointer vs redzoning\n\nIt turns out that SLUB redzoning (\"slub_debug=Z\") checks from\ns->object_size rather than from s->inuse (which is normally bumped to\nmake room for the freelist pointer), so a cache created with an object\nsize less than 24 would have the freelist pointer written beyond\ns->object_size, causing the redzone to be corrupted by the freelist\npointer. This was very visible with \"slub_debug=ZF\":\n\n BUG test (Tainted: G B ): Right Redzone overwritten\n -----------------------------------------------------------------------------\n\n INFO: 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. First byte 0x1a instead of 0xbb\n INFO: Slab 0xffffef3950b47000 objects=170 used=170 fp=0x0000000000000000 flags=0x8000000000000200\n INFO: Object 0xffff957ead1c05d8 @offset=1496 fp=0xffff957ead1c0620\n\n Redzone (____ptrval____): bb bb bb bb bb bb bb bb ........\n Object (____ptrval____): 00 00 00 00 00 f6 f4 a5 ........\n Redzone (____ptrval____): 40 1d e8 1a aa @....\n Padding (____ptrval____): 00 00 00 00 00 00 00 00 ........\n\nAdjust the offset to stay within s->object_size.\n\n(Note that no caches of in this size range are known to exist in the\nkernel currently.)"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mm/slub: en realidad corrige el puntero de lista libre frente a redzoning. Resulta que SLUB redzoning (\"slub_debug=Z\") verifica desde s->object_size en lugar de s->inuse (que normalmente se elimina para dejar espacio para el puntero de lista libre), por lo que un cach\u00e9 creado con un tama\u00f1o de objeto menor a 24 tendr\u00eda el puntero de lista libre escrito m\u00e1s all\u00e1 de s->object_size, causando que el puntero de lista libre corrompa la zona roja. Esto fue muy visible con \"slub_debug=ZF\": prueba de BUG(contaminada: GB): zona roja derecha sobrescrita ---------------------------- ------------------------------------------------- INFORMACI\u00d3N : 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. Primer byte 0x1a en lugar de 0xbb INFORMACI\u00d3N: slab 0xffffef3950b47000 objetos=170 usados=170 fp=0x0000000000000000 banderas=0x80000000000000200 INFORMACI\u00d3N: Objeto 0xffff957ead1c05d8 @offset=1496 fp=0xffff9 57ead1c0620 Zona roja (____ptrval____): bb bb bb bb bb bb bb bb .... .... Objeto (____ptrval____): 00 00 00 00 00 f6 f4 a5 ........ Redzone (____ptrval____): 40 1d e8 1a aa @.... Relleno (____ptrval____): 00 00 00 00 00 00 00 00 ........ Ajuste el desplazamiento para permanecer dentro de s->object_size. (Tenga en cuenta que actualmente no se sabe que existan cach\u00e9s de este rango de tama\u00f1o en el kernel)."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix vlan tunnel dst refcnt when egressing\n\nThe egress tunnel code uses dst_clone() and directly sets the result\nwhich is wrong because the entry might have 0 refcnt or be already deleted,\ncausing number of problems. It also triggers the WARN_ON() in dst_hold()[1]\nwhen a refcnt couldn't be taken. Fix it by using dst_hold_safe() and\nchecking if a reference was actually taken before setting the dst.\n\n[1] dmesg WARN_ON log and following refcnt errors\n WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]\n Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net\n CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014\n RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]\n Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49\n RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0\n RBP: ffff8881040c6700 R08: 0000000000000000 R09: 0000000000000001\n R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000\n R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401\n FS: 0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0\n Call Trace:\n br_handle_vlan+0xbc/0xca [bridge]\n __br_forward+0x23/0x164 [bridge]\n deliver_clone+0x41/0x48 [bridge]\n br_handle_frame_finish+0x36f/0x3aa [bridge]\n ? skb_dst+0x2e/0x38 [bridge]\n ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge]\n ? br_handle_frame_finish+0x3aa/0x3aa [bridge]\n br_handle_frame+0x2c3/0x377 [bridge]\n ? __skb_pull+0x33/0x51\n ? vlan_do_receive+0x4f/0x36a\n ? br_handle_frame_finish+0x3aa/0x3aa [bridge]\n __netif_receive_skb_core+0x539/0x7c6\n ? __list_del_entry_valid+0x16e/0x1c2\n __netif_receive_skb_list_core+0x6d/0xd6\n netif_receive_skb_list_internal+0x1d9/0x1fa\n gro_normal_list+0x22/0x3e\n dev_gro_receive+0x55b/0x600\n ? detach_buf_split+0x58/0x140\n napi_gro_receive+0x94/0x12e\n virtnet_poll+0x15d/0x315 [virtio_net]\n __napi_poll+0x2c/0x1c9\n net_rx_action+0xe6/0x1fb\n __do_softirq+0x115/0x2d8\n run_ksoftirqd+0x18/0x20\n smpboot_thread_fn+0x183/0x19c\n ? smpboot_unregister_percpu_thread+0x66/0x66\n kthread+0x10a/0x10f\n ? kthread_mod_delayed_work+0xb6/0xb6\n ret_from_fork+0x22/0x30\n ---[ end trace 49f61b07f775fd2b ]---\n dst_release: dst:00000000c02d677a refcnt:-1\n dst_release underflow"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: corrige el refcnt dst del t\u00fanel vlan al salir El c\u00f3digo del t\u00fanel de salida usa dst_clone() y establece directamente el resultado que es incorrecto porque la entrada puede tener 0 refcnt o ya estar eliminada , causando varios problemas. Tambi\u00e9n activa WARN_ON() en dst_hold()[1] cuando no se puede tomar una referencia. Solucionelo usando dst_hold_safe() y verificando si realmente se tom\u00f3 una referencia antes de configurar el dst. [1] Registro dmesg WARN_ON y siguientes errores de referencia ADVERTENCIA: CPU: 5 PID: 38 en include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [puente] M\u00f3dulos vinculados en: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU : 5 PID: 38 Comm: ksoftirqd/5 Kdump: cargado Contaminado: GW 5.13.0-rc3+ #360 Nombre del hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 01/04/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [puente] C\u00f3digo: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 f6 e8 64 a.C. 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 00000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08: 0000000000000000 R09: 00000000000000001 R10: 2ce93d0054fe0d00 R11: d00000e0000 R12: ffff888109515000 R13: 0000000000000000 R14: 0000000000000001 R15: 00000000000000401 FS: 0000000000000000(0000) 8822bf40000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Seguimiento de llamadas: br_handle_vlan+0xbc/0xca [puente] _forward+0x23/0x164 [puente] delivery_clone+0x41/0x48 [puente] br_handle_frame_finish+0x36f/ 0x3aa [puente] ? skb_dst+0x2e/0x38 [puente]? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [puente]? br_handle_frame_finish+0x3aa/0x3aa [puente] br_handle_frame+0x2c3/0x377 [puente]? __skb_pull+0x33/0x51? vlan_do_receive+0x4f/0x36a? br_handle_frame_finish+0x3aa/0x3aa [puente] __netif_receive_skb_core+0x539/0x7c6? __list_del_entry_valid+0x16e/0x1c2 __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140 napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9 net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirq d+0x18/0x20 smpboot_thread_fn+0x183/0x19c ? smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f? kthread_mod_delayed_work+0xb6/0xb6 ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1 dst_release underflow"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix vlan tunnel dst null pointer dereference\n\nThis patch fixes a tunnel_dst null pointer dereference due to lockless\naccess in the tunnel egress path. When deleting a vlan tunnel the\ntunnel_dst pointer is set to NULL without waiting a grace period (i.e.\nwhile it's still usable) and packets egressing are dereferencing it\nwithout checking. Use READ/WRITE_ONCE to annotate the lockless use of\ntunnel_id, use RCU for accessing tunnel_dst and make sure it is read\nonly once and checked in the egress path. The dst is already properly RCU\nprotected so we don't need to do anything fancy than to make sure\ntunnel_id and tunnel_dst are read only once and checked in the egress path."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: corrige la desreferencia del puntero null del t\u00fanel vlan dst Este parche corrige una desreferencia del puntero null de Tunnel_dst debido al acceso sin bloqueo en la ruta de salida del t\u00fanel. Al eliminar un t\u00fanel VLAN, el puntero Tunnel_dst se establece en NULL sin esperar un per\u00edodo de gracia (es decir, mientras a\u00fan se puede utilizar) y los paquetes que salen lo desreferencian sin verificarlo. Use READ/WRITE_ONCE para anotar el uso sin bloqueo de Tunnel_id, use RCU para acceder a Tunnel_dst y aseg\u00farese de que se lea solo una vez y se verifique en la ruta de salida. El dst ya est\u00e1 correctamente protegido por la RCU, por lo que no necesitamos hacer nada sofisticado m\u00e1s que asegurarnos de que Tunnel_id y Tunnel_dst se lean solo una vez y se verifiquen en la ruta de salida."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ll_temac: Make sure to free skb when it is completely used\n\nWith the skb pointer piggy-backed on the TX BD, we have a simple and\nefficient way to free the skb buffer when the frame has been transmitted.\nBut in order to avoid freeing the skb while there are still fragments from\nthe skb in use, we need to piggy-back on the TX BD of the skb, not the\nfirst.\n\nWithout this, we are doing use-after-free on the DMA side, when the first\nBD of a multi TX BD packet is seen as completed in xmit_done, and the\nremaining BDs are still being processed."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:ll_temac: Aseg\u00farate de liberar skb cuando est\u00e9 completamente utilizado. Con el puntero skb acoplado en la BD TX, tenemos una forma sencilla y eficaz de liberar el buffer skb. cuando la trama ha sido transmitida. Pero para evitar liberar el skb mientras todav\u00eda hay fragmentos del skb en uso, debemos aprovechar el BD TX del skb, no el primero. Sin esto, estamos haciendo use after free en el lado DMA, cuando el primer BD de un paquete BD de transmisi\u00f3n m\u00faltiple se considera completado en xmit_done y los BD restantes todav\u00eda se est\u00e1n procesando."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: fix deadlock in AP/VLAN handling\n\nSyzbot reports that when you have AP_VLAN interfaces that are up\nand close the AP interface they belong to, we get a deadlock. No\nsurprise - since we dev_close() them with the wiphy mutex held,\nwhich goes back into the netdev notifier in cfg80211 and tries to\nacquire the wiphy mutex there.\n\nTo fix this, we need to do two things:\n 1) prevent changing iftype while AP_VLANs are up, we can't\n easily fix this case since cfg80211 already calls us with\n the wiphy mutex held, but change_interface() is relatively\n rare in drivers anyway, so changing iftype isn't used much\n (and userspace has to fall back to down/change/up anyway)\n 2) pull the dev_close() loop over VLANs out of the wiphy mutex\n section in the normal stop case"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac80211: corrige el punto muerto en el manejo de AP/VLAN. Syzbot informa que cuando tienes interfaces AP_VLAN activas y cierras la interfaz AP a la que pertenecen, obtenemos un punto muerto. No es de extra\u00f1ar, ya que los dev_close() los usamos con el mutex wiphy retenido, lo que regresa al notificador netdev en cfg80211 e intenta adquirir el mutex wiphy all\u00ed. Para solucionar esto, debemos hacer dos cosas: 1) evitar cambiar iftype mientras las AP_VLAN est\u00e9n activas, no podemos solucionar f\u00e1cilmente este caso ya que cfg80211 ya nos llama con el mutex wiphy retenido, pero change_interface() es relativamente raro en los controladores de todos modos , por lo que cambiar iftype no se usa mucho (y el espacio de usuario tiene que volver a bajar/cambiar/arriba de todos modos) 2) extraiga el bucle dev_close() sobre las VLAN de la secci\u00f3n wiphy mutex en el caso de detenci\u00f3n normal"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer\n\nBoth Intel and AMD consider it to be architecturally valid for XRSTOR to\nfail with #PF but nonetheless change the register state. The actual\nconditions under which this might occur are unclear [1], but it seems\nplausible that this might be triggered if one sibling thread unmaps a page\nand invalidates the shared TLB while another sibling thread is executing\nXRSTOR on the page in question.\n\n__fpu__restore_sig() can execute XRSTOR while the hardware registers\nare preserved on behalf of a different victim task (using the\nfpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but\nmodify the registers.\n\nIf this happens, then there is a window in which __fpu__restore_sig()\ncould schedule out and the victim task could schedule back in without\nreloading its own FPU registers. This would result in part of the FPU\nstate that __fpu__restore_sig() was attempting to load leaking into the\nvictim task's user-visible state.\n\nInvalidate preserved FPU registers on XRSTOR failure to prevent this\nsituation from corrupting any state.\n\n[1] Frequent readers of the errata lists might imagine \"complex\n microarchitectural conditions\"."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Invalida el estado de la FPU despu\u00e9s de un XRSTOR fallido desde un b\u00fafer de usuario. Tanto Intel como AMD consideran que es arquitect\u00f3nicamente v\u00e1lido que XRSTOR falle con #PF pero aun as\u00ed cambie el estado del registro. . Las condiciones reales bajo las cuales esto podr\u00eda ocurrir no est\u00e1n claras [1], pero parece plausible que esto pueda desencadenarse si un hilo hermano desasigna una p\u00e1gina e invalida el TLB compartido mientras otro hilo hermano est\u00e1 ejecutando XRSTOR en la p\u00e1gina en cuesti\u00f3n. __fpu__restore_sig() puede ejecutar XRSTOR mientras los registros de hardware se conservan en nombre de una tarea de v\u00edctima diferente (usando el mecanismo fpu_fpregs_owner_ctx) y, en teor\u00eda, XRSTOR podr\u00eda fallar pero modificar los registros. Si esto sucede, entonces hay una ventana en la que __fpu__restore_sig() podr\u00eda programar la salida y la tarea de la v\u00edctima podr\u00eda volver a programarse sin recargar sus propios registros FPU. Esto resultar\u00eda en parte del estado de la FPU en el que __fpu__restore_sig() intentaba cargar una filtraci\u00f3n en el estado visible para el usuario de la tarea de la v\u00edctima. Invalide los registros FPU preservados en caso de falla de XRSTOR para evitar que esta situaci\u00f3n corrompa cualquier estado. [1] Los lectores frecuentes de las listas de erratas podr\u00edan imaginar \"condiciones microarquitect\u00f3nicas complejas\"."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Prevent state corruption in __fpu__restore_sig()\n\nThe non-compacted slowpath uses __copy_from_user() and copies the entire\nuser buffer into the kernel buffer, verbatim. This means that the kernel\nbuffer may now contain entirely invalid state on which XRSTOR will #GP.\nvalidate_user_xstate_header() can detect some of that corruption, but that\nleaves the onus on callers to clear the buffer.\n\nPrior to XSAVES support, it was possible just to reinitialize the buffer,\ncompletely, but with supervisor states that is not longer possible as the\nbuffer clearing code split got it backwards. Fixing that is possible but\nnot corrupting the state in the first place is more robust.\n\nAvoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate()\nwhich validates the XSAVE header contents before copying the actual states\nto the kernel. copy_user_to_xstate() was previously only called for\ncompacted-format kernel buffers, but it works for both compacted and\nnon-compacted forms.\n\nUsing it for the non-compacted form is slower because of multiple\n__copy_from_user() operations, but that cost is less important than robust\ncode in an already slow path.\n\n[ Changelog polished by Dave Hansen ]"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: x86/fpu: evita la corrupci\u00f3n del estado en __fpu__restore_sig() La ruta lenta no compactada usa __copy_from_user() y copia todo el b\u00fafer del usuario en el b\u00fafer del kernel, palabra por palabra. Esto significa que el b\u00fafer del kernel ahora puede contener un estado completamente inv\u00e1lido en el que XRSTOR realizar\u00e1 #GP. validar_user_xstate_header() puede detectar parte de esa corrupci\u00f3n, pero eso deja a las personas que llaman la responsabilidad de borrar el b\u00fafer. Antes de la compatibilidad con XSAVES, era posible simplemente reinicializar el b\u00fafer por completo, pero con los estados del supervisor eso ya no es posible porque la divisi\u00f3n del c\u00f3digo de borrado del b\u00fafer lo hac\u00eda al rev\u00e9s. Arreglar eso es posible, pero no corromper al Estado en primer lugar es m\u00e1s s\u00f3lido. Evite la corrupci\u00f3n del b\u00fafer XSAVE del kernel utilizando copy_user_to_xstate() que valida el contenido del encabezado XSAVE antes de copiar los estados reales al kernel. copy_user_to_xstate() anteriormente solo se llamaba para buffers del kernel en formato compacto, pero funciona tanto para formatos compactos como no compactos. Usarlo para el formato no compacto es m\u00e1s lento debido a m\u00faltiples operaciones __copy_from_user(), pero ese costo es menos importante que el c\u00f3digo robusto en una ruta que ya es lenta. [Registro de cambios pulido por Dave Hansen]"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/ioremap: Map EFI-reserved memory as encrypted for SEV\n\nSome drivers require memory that is marked as EFI boot services\ndata. In order for this memory to not be re-used by the kernel\nafter ExitBootServices(), efi_mem_reserve() is used to preserve it\nby inserting a new EFI memory descriptor and marking it with the\nEFI_MEMORY_RUNTIME attribute.\n\nUnder SEV, memory marked with the EFI_MEMORY_RUNTIME attribute needs to\nbe mapped encrypted by Linux, otherwise the kernel might crash at boot\nlike below:\n\n EFI Variables Facility v0.08 2004-May-17\n general protection fault, probably for non-canonical address 0x3597688770a868b2: 0000 [#1] SMP NOPTI\n CPU: 13 PID: 1 Comm: swapper/0 Not tainted 5.12.4-2-default #1 openSUSE Tumbleweed\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:efi_mokvar_entry_next\n [...]\n Call Trace:\n efi_mokvar_sysfs_init\n ? efi_mokvar_table_init\n do_one_initcall\n ? __kmalloc\n kernel_init_freeable\n ? rest_init\n kernel_init\n ret_from_fork\n\nExpand the __ioremap_check_other() function to additionally check for\nthis other type of boot data reserved at runtime and indicate that it\nshould be mapped encrypted for an SEV guest.\n\n [ bp: Massage commit message. ]"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: x86/ioremap: asigne la memoria reservada de EFI como cifrada para SEV. Algunos controladores requieren memoria marcada como datos de servicios de arranque de EFI. Para que el kernel no reutilice esta memoria despu\u00e9s de ExitBootServices(), se utiliza efi_mem_reserve() para preservarla insertando un nuevo descriptor de memoria EFI y marc\u00e1ndolo con el atributo EFI_MEMORY_RUNTIME. En SEV, la memoria marcada con el atributo EFI_MEMORY_RUNTIME debe ser asignada cifrada por Linux; de lo contrario, el kernel podr\u00eda fallar en el arranque como se muestra a continuaci\u00f3n: EFI Variables Facility v0.08 2004-May-17 falla de protecci\u00f3n general, probablemente para la direcci\u00f3n no can\u00f3nica 0x3597688770a868b2: 0000 [#1] SMP NOPTI CPU: 13 PID: 1 Comm: swapper/0 No contaminado 5.12.4-2-default #1 openSUSE Tumbleweed Nombre del hardware: PC est\u00e1ndar QEMU (Q35 + ICH9, 2009), BIOS 0.0.0 02 /06/2015 RIP: 0010:efi_mokvar_entry_next [...] Seguimiento de llamadas: efi_mokvar_sysfs_init? efi_mokvar_table_init do_one_initcall? __kmalloc kernel_init_freeable? rest_init kernel_init ret_from_fork Expanda la funci\u00f3n __ioremap_check_other() para verificar adicionalmente este otro tipo de datos de arranque reservados en tiempo de ejecuci\u00f3n e indicar que deben asignarse cifrados para un invitado SEV. [pb: mensaje de confirmaci\u00f3n de masaje. ]"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: aardvark: Fix kernel panic during PIO transfer\n\nTrying to start a new PIO transfer by writing value 0 in PIO_START register\nwhen previous transfer has not yet completed (which is indicated by value 1\nin PIO_START) causes an External Abort on CPU, which results in kernel\npanic:\n\n SError Interrupt on CPU0, code 0xbf000002 -- SError\n Kernel panic - not syncing: Asynchronous SError Interrupt\n\nTo prevent kernel panic, it is required to reject a new PIO transfer when\nprevious one has not finished yet.\n\nIf previous PIO transfer is not finished yet, the kernel may issue a new\nPIO request only if the previous PIO transfer timed out.\n\nIn the past the root cause of this issue was incorrectly identified (as it\noften happens during link retraining or after link down event) and special\nhack was implemented in Trusted Firmware to catch all SError events in EL3,\nto ignore errors with code 0xbf000002 and not forwarding any other errors\nto kernel and instead throw panic from EL3 Trusted Firmware handler.\n\nLinks to discussion and patches about this issue:\nhttps://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50\nhttps://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/\nhttps://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/\nhttps://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541\n\nBut the real cause was the fact that during link retraining or after link\ndown event the PIO transfer may take longer time, up to the 1.44s until it\ntimes out. This increased probability that a new PIO transfer would be\nissued by kernel while previous one has not finished yet.\n\nAfter applying this change into the kernel, it is possible to revert the\nmentioned TF-A hack and SError events do not have to be caught in TF-A EL3."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: PCI: aardvark: solucion\u00f3 el p\u00e1nico del kernel durante la transferencia de PIO. Intentar iniciar una nueva transferencia de PIO escribiendo el valor 0 en el registro PIO_START cuando la transferencia anterior a\u00fan no se ha completado (que se indica con el valor 1). en PIO_START) provoca un aborto externo en la CPU, lo que resulta en p\u00e1nico del kernel: Interrupci\u00f3n de SError en CPU0, c\u00f3digo 0xbf000002 - P\u00e1nico del kernel de SError - no se sincroniza: Interrupci\u00f3n de SError asincr\u00f3nica Para evitar el p\u00e1nico del kernel, es necesario rechazar una nueva transferencia de PIO cuando el anterior a\u00fan no ha terminado. Si la transferencia PIO anterior a\u00fan no ha finalizado, el kernel puede emitir una nueva solicitud PIO solo si se agot\u00f3 el tiempo de espera de la transferencia PIO anterior. En el pasado, la causa root de este problema se identific\u00f3 incorrectamente (como sucede a menudo durante el reentrenamiento del enlace o despu\u00e9s de un evento de ca\u00edda del enlace) y se implement\u00f3 un truco especial en Trusted Firmware para detectar todos los eventos de SError en EL3, para ignorar los errores con el c\u00f3digo 0xbf000002 y no reenviar cualquier otro error al kernel y en su lugar generar p\u00e1nico desde el controlador de firmware confiable EL3. Enlaces a discusiones y parches sobre este problema: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci /20190316161243.29517-1-repk@triplefau.lt/ https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/ https://review.trustedfirmware.org/c/TF-A/trusted -firmware-a/+/1541 Pero la causa real fue el hecho de que durante el reentrenamiento del enlace o despu\u00e9s de un evento de ca\u00edda del enlace, la transferencia de PIO puede tardar m\u00e1s tiempo, hasta 1,44 segundos hasta que se agote el tiempo de espera. Esto aumenta la probabilidad de que el kernel emita una nueva transferencia PIO mientras que la anterior a\u00fan no ha finalizado. Despu\u00e9s de aplicar este cambio en el kernel, es posible revertir el hack de TF-A mencionado y los eventos SError no tienen que detectarse en TF-A EL3."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Immediately reset the MMU context when the SMM flag is cleared\n\nImmediately reset the MMU context when the vCPU's SMM flag is cleared so\nthat the SMM flag in the MMU role is always synchronized with the vCPU's\nflag. If RSM fails (which isn't correctly emulated), KVM will bail\nwithout calling post_leave_smm() and leave the MMU in a bad state.\n\nThe bad MMU role can lead to a NULL pointer dereference when grabbing a\nshadow page's rmap for a page fault as the initial lookups for the gfn\nwill happen with the vCPU's SMM flag (=0), whereas the rmap lookup will\nuse the shadow page's SMM flag, which comes from the MMU (=1). SMM has\nan entirely different set of memslots, and so the initial lookup can find\na memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).\n\n general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]\n RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947\n Code: <42> 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44\n RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40\n RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001\n RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002\n R10: ffffed10065a6002 R11: 0000000000000000 R12: dffffc0000000000\n R13: 0000000000000003 R14: 0000000000000001 R15: 0000000000000000\n FS: 000000000124b300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 0000000028e31000 CR4: 00000000001526e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n rmap_add arch/x86/kvm/mmu/mmu.c:965 [inline]\n mmu_set_spte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604\n __direct_map arch/x86/kvm/mmu/mmu.c:2862 [inline]\n direct_page_fault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769\n kvm_mmu_do_page_fault arch/x86/kvm/mmu.h:124 [inline]\n kvm_mmu_page_fault+0x199/0x1440 arch/x86/kvm/mmu/mmu.c:5065\n vmx_handle_exit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122\n vcpu_enter_guest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428\n vcpu_run+0x416/0xc20 arch/x86/kvm/x86.c:9494\n kvm_arch_vcpu_ioctl_run+0x4e8/0xa40 arch/x86/kvm/x86.c:9722\n kvm_vcpu_ioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3460\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:1069 [inline]\n __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055\n do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x440ce9"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: restablece inmediatamente el contexto de MMU cuando se borra el indicador SMM Restablece inmediatamente el contexto de MMU cuando se borra el indicador SMM de la vCPU para que el indicador SMM en la funci\u00f3n MMU est\u00e9 siempre sincronizado con el indicador de la vCPU. Si RSM falla (que no se emula correctamente), KVM se retirar\u00e1 sin llamar a post_leave_smm() y dejar\u00e1 la MMU en mal estado. La funci\u00f3n incorrecta de MMU puede provocar una desreferencia del puntero NULL al tomar el rmap de una p\u00e1gina oculta para una falla de p\u00e1gina, ya que las b\u00fasquedas iniciales para gfn se realizar\u00e1n con el indicador SMM de la vCPU (=0), mientras que la b\u00fasqueda de rmap utilizar\u00e1 el SMM de la p\u00e1gina oculta. bandera, que proviene de la MMU (=1). SMM tiene un conjunto de ranuras de memoria completamente diferente, por lo que la b\u00fasqueda inicial puede encontrar una ranura de memoria (SMM=0) y luego explotar en la b\u00fasqueda de ranura de memoria de rmap (SMM=1). falla de protecci\u00f3n general, probablemente para direcci\u00f3n no can\u00f3nica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en rango [0x0000000000000000-0x00000000000000007] CPU: 1 PID: 8410 Comm: No contaminado 5.13.0 -rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [en l\u00ednea] RIP: 0010: gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947 C\u00f3digo: <42> 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44 RSP:ffffc90000ffe f98 EFLAGS : 00010246 RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40 RDX: 00000000000000000 RSI: 0000000000000001 RDI: 00000000000 00001 RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002 R10: ffffed10065a6002 R11: 00000000000000000 R12: dffffc0000000000 R13: 0000000000003 R14: 0000000000000001 R15: 0000000000000000 FS: 000000000124b300 (0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 8e31000 CR4: 00000000001526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: rmap_add arch/x86/kvm/mmu/mmu.c:965 [en l\u00ednea] mmu_set_spte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604 __direct_map arch/x86/kvm/mmu/mmu. c:2862 [en l\u00ednea] direct_page_fault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769 kvm_mmu_do_page_fault arch/x86/kvm/mmu.h:124 [en l\u00ednea] kvm_mmu_page_fault+0x199/0x1440 arch/x86/kvm/ mmu/mmu.c:5065 vmx_handle_exit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122 vcpu_enter_guest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428 vcpu_run+0x416/0xc20 arch/x86/ kvm/x86.c:9494 kvm_arch_vcpu_ioctl_run+0x4e8/0xa40 arch/x86/kvm/x86.c:9722 kvm_vcpu_ioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c :3460 vfs_ioctl fs/ioctl.c:51 [en l\u00ednea] __do_sys_ioctl fs/ioctl.c:1069 [en l\u00ednea] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c :47 entrada_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x440ce9"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: mcba_usb: fix memory leak in mcba_usb\n\nSyzbot reported memory leak in SocketCAN driver for Microchip CAN BUS\nAnalyzer Tool. The problem was in unfreed usb_coherent.\n\nIn mcba_usb_start() 20 coherent buffers are allocated and there is\nnothing, that frees them:\n\n1) In callback function the urb is resubmitted and that's all\n2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER\n is not set (see mcba_usb_start) and this flag cannot be used with\n coherent buffers.\n\nFail log:\n| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected\n| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)\n\nSo, all allocated buffers should be freed with usb_free_coherent()\nexplicitly\n\nNOTE:\nThe same pattern for allocating and freeing coherent buffers\nis used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: can: mcba_usb: repara la p\u00e9rdida de memoria en mcba_usb. Syzbot inform\u00f3 una p\u00e9rdida de memoria en el controlador SocketCAN para la herramienta Microchip CAN BUS Analyzer. El problema estaba en usb_coherent no liberado. En mcba_usb_start() se asignan 20 buffers coherentes y no hay nada que los libere: 1) En la funci\u00f3n de devoluci\u00f3n de llamada, la urb se vuelve a enviar y eso es todo 2) En la funci\u00f3n de desconexi\u00f3n, las urbs simplemente se eliminan, pero URB_FREE_BUFFER no est\u00e1 configurado (ver mcba_usb_start) y Esta bandera no se puede utilizar con buffers coherentes. Registro de errores: | [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: dispositivo desconectado | [ 1367.059384][ T8420] kmemleak: 20 nuevas p\u00e9rdidas de memoria sospechosas (ver /sys/kernel/debug/kmem) Por lo tanto, todos los buffers asignados deben liberarse con usb_free_coherent() expl\u00edcitamente NOTA: Se utiliza el mismo patr\u00f3n para asignar y liberar buffers coherentes en controladores/net/can/usb/kvaser_usb/kvaser_usb_core.c"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: fix Use-after-Free, hold skb ref while in use\n\nThis patch fixes a Use-after-Free found by the syzbot.\n\nThe problem is that a skb is taken from the per-session skb queue,\nwithout incrementing the ref count. This leads to a Use-after-Free if\nthe skb is taken concurrently from the session queue due to a CTS."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: corrige Use-after-Free, mantenga presionada la referencia skb mientras est\u00e1 en uso. Este parche corrige un Use-after-Free encontrado por syzbot. El problema es que se toma un skb de la cola de skb por sesi\u00f3n, sin incrementar el recuento de referencias. Esto conduce a un use after free si el skb se toma simult\u00e1neamente de la cola de sesi\u00f3n debido a un CTS."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nregulator: rt4801: Fix NULL pointer dereference if priv->enable_gpios is NULL\n\ndevm_gpiod_get_array_optional may return NULL if no GPIO was assigned."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: regulador: rt4801: corrige la desreferencia del puntero NULL si priv->enable_gpios es NULL, devm_gpiod_get_array_optional puede devolver NULL si no se asign\u00f3 ning\u00fan GPIO."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nphy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init()\n\nUse clk_disable_unprepare() in the error path of mtk_phy_init() to fix\nsome resource leaks."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: phy: phy-mtk-tphy: solucione algunas fugas de recursos en mtk_phy_init() Utilice clk_disable_unprepare() en la ruta de error de mtk_phy_init() para solucionar algunas fugas de recursos."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: fix potential use-after-free in ec_bhf_remove\n\nstatic void ec_bhf_remove(struct pci_dev *dev)\n{\n...\n\tstruct ec_bhf_priv *priv = netdev_priv(net_dev);\n\n\tunregister_netdev(net_dev);\n\tfree_netdev(net_dev);\n\n\tpci_iounmap(dev, priv->dma_io);\n\tpci_iounmap(dev, priv->io);\n...\n}\n\npriv is netdev private data, but it is used\nafter free_netdev(). It can cause use-after-free when accessing priv\npointer. So, fix it by moving free_netdev() after pci_iounmap()\ncalls."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: soluciona el posible use after free en ec_bhf_remove static void ec_bhf_remove(struct pci_dev *dev) { ... struct ec_bhf_priv *priv = netdev_priv(net_dev); anular el registro_netdev(net_dev); free_netdev(net_dev); pci_iounmap(dev, priv->dma_io); pci_iounmap(dev, priv->io); ... } priv son datos privados de netdev, pero se usan despu\u00e9s de free_netdev(). Puede causar use after free al acceder al puntero privado. Entonces, solucionelo moviendo free_netdev() despu\u00e9s de las llamadas a pci_iounmap()."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: cdc_eem: fix tx fixup skb leak\n\nwhen usbnet transmit a skb, eem fixup it in eem_tx_fixup(),\nif skb_copy_expand() failed, it return NULL,\nusbnet_start_xmit() will have no chance to free original skb.\n\nfix it by free orginal skb in eem_tx_fixup() first,\nthen check skb clone status, if failed, return NULL to usbnet."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: cdc_eem: corrige la fuga de skb de reparaci\u00f3n de tx cuando usbnet transmite un skb, eem lo repara en eem_tx_fixup(), si skb_copy_expand() falla, devuelve NULL, usbnet_start_xmit() No tendr\u00e1 posibilidad de liberar el skb original. solucionelo primero con skb original gratuito en eem_tx_fixup(), luego verifique el estado del clon de skb, si falla, devuelva NULL a usbnet."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hamradio: fix memory leak in mkiss_close\n\nMy local syzbot instance hit memory leak in\nmkiss_open()[1]. The problem was in missing\nfree_netdev() in mkiss_close().\n\nIn mkiss_open() netdevice is allocated and then\nregistered, but in mkiss_close() netdevice was\nonly unregistered, but not freed.\n\nFail log:\n\nBUG: memory leak\nunreferenced object 0xffff8880281ba000 (size 4096):\n comm \"syz-executor.1\", pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0.............\n 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*............\n backtrace:\n [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n [<ffffffff8706e7e8>] alloc_netdev_mqs+0x98/0xe80\n [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff8880141a9a00 (size 96):\n comm \"syz-executor.1\", pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(....\n 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@..........\n backtrace:\n [<ffffffff8709f68b>] __hw_addr_create_ex+0x5b/0x310\n [<ffffffff8709fb38>] __hw_addr_add_ex+0x1f8/0x2b0\n [<ffffffff870a0c7b>] dev_addr_init+0x10b/0x1f0\n [<ffffffff8706e88b>] alloc_netdev_mqs+0x13b/0xe80\n [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff8880219bfc00 (size 512):\n comm \"syz-executor.1\", pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............\n 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n [<ffffffff8706eec7>] alloc_netdev_mqs+0x777/0xe80\n [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff888029b2b200 (size 256):\n comm \"syz-executor.1\", pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n [<ffffffff8706f062>] alloc_netdev_mqs+0x912/0xe80\n [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net: hamradio: corrige la p\u00e9rdida de memoria en mkiss_close. Mi instancia local de syzbot tuvo una p\u00e9rdida de memoria en mkiss_open()[1]. El problema estaba en que faltaba free_netdev() en mkiss_close(). En mkiss_open() el dispositivo de red se asigna y luego se registra, pero en mkiss_close() el dispositivo de red solo se anula del registro, pero no se libera. Registro de errores: ERROR: p\u00e9rdida de memoria, objeto sin referencia 0xffff8880281ba000 (tama\u00f1o 4096): comunicaci\u00f3n \"syz-executor.1\", pid 11443, santiam\u00e9n 4295046091 (edad 17,660 s) volcado hexadecimal (primeros 32 bytes): 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0............. 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*....... .... seguimiento: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x98/0xe80 [] mkiss_open+0xb2/0x6f0 [] tty_ldisc_open+0x9b/0x110 [ ] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] Entry_SYSCALL_64_after_hwframe+0x44/0xae ERROR : p\u00e9rdida de memoria objeto sin referencia 0xffff8880141a9a00 (tama\u00f1o 96): comm \"syz-executor.1\", pid 11443, jiffies 4295046091 (edad 17.660s) volcado hexadecimal (primeros 32 bytes): e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(.... 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@....... .. seguimiento: [] __hw_addr_create_ex+0x5b/0x310 [] __hw_addr_add_ex+0x1f8/0x2b0 [] f0 [] alloc_netdev_mqs+0x13b/0xe80 [] mkiss_open +0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] Entry_SYSCALL_64_after_hwframe+0x44/0xae ERROR: p\u00e9rdida de memoria objeto sin referencia 0xffff8880219bfc00 (tama\u00f1o 512): comm \"syz-executor.1\", pid 11443, jiffies 95046091 (edad 17.660 a\u00f1os) volcado hexadecimal (primeros 32 bytes): 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ...(............ 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................ rastreo inverso: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x777/0xe80 [] mkiss_open+0xb2 /0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] Entry_SYSCALL_64_after_hwframe+0x44/0xae ERROR: p\u00e9rdida de memoria objeto sin referencia 0xffff888029b2b200 (tama\u00f1o 256): comm \"syz-executor.1\", pid 11443, jiffies 046091 (edad 17.660 a\u00f1os) volcado hexadecimal (primero 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ rastreo inverso: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x912/0xe80 [] mkiss_open+0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+ 0x3a/0xb0 [] entrada_SYSCALL_64_after_hwframe+0x44/0xae"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv4: fix memory leak in ip_mc_add1_src\n\nBUG: memory leak\nunreferenced object 0xffff888101bc4c00 (size 32):\n comm \"syz-executor527\", pid 360, jiffies 4294807421 (age 19.329s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................\n backtrace:\n [<00000000f17c5244>] kmalloc include/linux/slab.h:558 [inline]\n [<00000000f17c5244>] kzalloc include/linux/slab.h:688 [inline]\n [<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline]\n [<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095\n [<000000001cb99709>] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416\n [<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline]\n [<0000000052cf19ed>] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423\n [<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857\n [<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117\n [<00000000bdb993a8>] __do_sys_setsockopt net/socket.c:2128 [inline]\n [<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125 [inline]\n [<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125\n [<000000006a1ffdbd>] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47\n [<00000000b11467c4>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nIn commit 24803f38a5c0 (\"igmp: do not remove igmp souce list info when set\nlink down\"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed,\nbecause it was also called in igmpv3_clear_delrec().\n\nRough callgraph:\n\ninetdev_destroy\n-> ip_mc_destroy_dev\n -> igmpv3_clear_delrec\n -> ip_mc_clear_src\n-> RCU_INIT_POINTER(dev->ip_ptr, NULL)\n\nHowever, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn't\nrelease in_dev->mc_list->sources. And RCU_INIT_POINTER() assigns the\nNULL to dev->ip_ptr. As a result, in_dev cannot be obtained through\ninetdev_by_index() and then in_dev->mc_list->sources cannot be released\nby ip_mc_del1_src() in the sock_close. Rough call sequence goes like:\n\nsock_close\n-> __sock_release\n -> inet_release\n -> ip_mc_drop_socket\n -> inetdev_by_index\n -> ip_mc_leave_src\n -> ip_mc_del_src\n -> ip_mc_del1_src\n\nSo we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to free\nin_dev->mc_list->sources."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv4: corrige la p\u00e9rdida de memoria en ip_mc_add1_src. BUG: p\u00e9rdida de memoria objeto sin referencia 0xffff888101bc4c00 (tama\u00f1o 32): comm \"syz-executor527\", pid 360, jiffies 4294807421 (edad 19.329s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................ backtrace: [<00000000f17c5244>] kmalloc include/linux/slab.h:558 [en l\u00ednea] [<00000000f17c5244>] kzalloc include/ linux/slab.h:688 [en l\u00ednea] [<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971 [en l\u00ednea] [<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095 <000000001cb99709 >] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416 [<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [en l\u00ednea] [<0000000052cf19ed>] 0net/ipv4/ip_sockglue. c:1423 [<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857 [<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117 [<00000000bdb993 a8>] __do_sys_setsockopt net/socket.c :2128 [en l\u00ednea] [<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125 [en l\u00ednea] [<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125 [<000000006a 1ffdbd>] do_syscall_64+0x40/0x80 arch/ x86/entry/common.c:47 [<00000000b11467c4>] Entry_SYSCALL_64_after_hwframe+0x44/0xae En la confirmaci\u00f3n 24803f38a5c0 (\"igmp: no eliminar la informaci\u00f3n de la lista de fuentes de igmp cuando se establece el enlace\"), se elimin\u00f3 ip_mc_clear_src() en ip_mc_destroy_dev() , porque tambi\u00e9n fue llamado en igmpv3_clear_delrec(). Gr\u00e1fico de llamada aproximado: inetdev_destroy -> ip_mc_destroy_dev -> igmpv3_clear_delrec -> ip_mc_clear_src -> RCU_INIT_POINTER(dev->ip_ptr, NULL) Sin embargo, ip_mc_clear_src() llamado en igmpv3_clear_delrec() no libera in_dev->mc_list->sources. Y RCU_INIT_POINTER() asigna NULL a dev->ip_ptr. Como resultado, in_dev no se puede obtener a trav\u00e9s de inetdev_by_index() y luego in_dev->mc_list->sources no se puede liberar mediante ip_mc_del1_src() en sock_close. La secuencia de llamada aproximada es as\u00ed: sock_close -> __sock_release -> inet_release -> ip_mc_drop_socket -> inetdev_by_index -> ip_mc_leave_src -> ip_mc_del_src -> ip_mc_del1_src Entonces todav\u00eda necesitamos llamar a ip_mc_clear_src() en ip_mc_destroy_dev() para liberar in_dev->mc_list ->fuentes ."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: fix possible use-after-free in smsc75xx_bind\n\nThe commit 46a8b29c6306 (\"net: usb: fix memory leak in smsc75xx_bind\")\nfails to clean up the work scheduled in smsc75xx_reset->\nsmsc75xx_set_multicast, which leads to use-after-free if the work is\nscheduled to start after the deallocation. In addition, this patch\nalso removes a dangling pointer - dev->data[0].\n\nThis patch calls cancel_work_sync to cancel the scheduled work and set\nthe dangling pointer to NULL."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:usb: corrige posible use after free en smsc75xx_bind. La confirmaci\u00f3n 46a8b29c6306 (\"net:usb: corrige la p\u00e9rdida de memoria en smsc75xx_bind\") no logra limpiar el trabajo programado en smsc75xx_reset -> smsc75xx_set_multicast, lo que genera use after free si el trabajo est\u00e1 programado para comenzar despu\u00e9s de la desasignaci\u00f3n. Adem\u00e1s, este parche tambi\u00e9n elimina un puntero colgante: dev->data[0]. Este parche llama a cancel_work_sync para cancelar el trabajo programado y establecer el puntero colgante en NULL."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: qrtr: fix OOB Read in qrtr_endpoint_post\n\nSyzbot reported slab-out-of-bounds Read in\nqrtr_endpoint_post. The problem was in wrong\n_size_ type:\n\n\tif (len != ALIGN(size, 4) + hdrlen)\n\t\tgoto err;\n\nIf size from qrtr_hdr is 4294967293 (0xfffffffd), the result of\nALIGN(size, 4) will be 0. In case of len == hdrlen and size == 4294967293\nin header this check won't fail and\n\n\tskb_put_data(skb, data + hdrlen, size);\n\nwill read out of bound from data, which is hdrlen allocated block."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: qrtr: arreglar OOB Lectura en qrtr_endpoint_post. Syzbot report\u00f3 slab-out-of-bounds Lectura en qrtr_endpoint_post. El problema estaba en el tipo de _tama\u00f1o_ incorrecto: if (len != ALIGN(size, 4) + hdrlen) goto err; Si el tama\u00f1o de qrtr_hdr es 4294967293 (0xfffffffd), el resultado de ALIGN(size, 4) ser\u00e1 0. En caso de len == hdrlen y size == 4294967293 en el encabezado, esta verificaci\u00f3n no fallar\u00e1 y skb_put_data(skb, data + hdrlen, tama\u00f1o); leer\u00e1 fuera de los l\u00edmites de los datos, que son bloques asignados hdrlen."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nethtool: strset: fix message length calculation\n\nOuter nest for ETHTOOL_A_STRSET_STRINGSETS is not accounted for.\nThis may result in ETHTOOL_MSG_STRSET_GET producing a warning like:\n\n calculated message payload length (684) not sufficient\n WARNING: CPU: 0 PID: 30967 at net/ethtool/netlink.c:369 ethnl_default_doit+0x87a/0xa20\n\nand a splat.\n\nAs usually with such warnings three conditions must be met for the warning\nto trigger:\n - there must be no skb size rounding up (e.g. reply_size of 684);\n - string set must be per-device (so that the header gets populated);\n - the device name must be at least 12 characters long.\n\nall in all with current user space it looks like reading priv flags\nis the only place this could potentially happen. Or with syzbot :)"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ethtool: strset: correcci\u00f3n del c\u00e1lculo de la longitud del mensaje. No se tiene en cuenta el nido externo para ETHTOOL_A_STRSET_STRINGSETS. Esto puede provocar que ETHTOOL_MSG_STRSET_GET produzca una advertencia como: la longitud calculada de el payload del mensaje (684) no es suficiente ADVERTENCIA: CPU: 0 PID: 30967 en net/ethtool/netlink.c:369 ethnl_default_doit+0x87a/0xa20 y un s\u00edmbolo. Como suele ocurrir con este tipo de advertencias, se deben cumplir tres condiciones para que se active la advertencia: - no debe haber ning\u00fan tama\u00f1o de skb redondeado hacia arriba (por ejemplo, tama\u00f1o_respuesta de 684); - el conjunto de cadenas debe ser por dispositivo (para que se complete el encabezado); - el nombre del dispositivo debe tener al menos 12 caracteres. Con todo, con el espacio de usuario actual, parece que leer indicadores privados es el \u00fanico lugar donde esto podr\u00eda suceder. O con syzbot :)"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix soft lookup in subflow_error_report()\n\nMaxim reported a soft lookup in subflow_error_report():\n\n watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]\n RIP: 0010:native_queued_spin_lock_slowpath\n RSP: 0018:ffffa859c0003bc0 EFLAGS: 00000202\n RAX: 0000000000000101 RBX: 0000000000000001 RCX: 0000000000000000\n RDX: ffff9195c2772d88 RSI: 0000000000000000 RDI: ffff9195c2772d88\n RBP: ffff9195c2772d00 R08: 00000000000067b0 R09: c6e31da9eb1e44f4\n R10: ffff9195ef379700 R11: ffff9195edb50710 R12: ffff9195c2772d88\n R13: ffff9195f500e3d0 R14: ffff9195ef379700 R15: ffff9195ef379700\n FS: 0000000000000000(0000) GS:ffff91961f400000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000c000407000 CR3: 0000000002988000 CR4: 00000000000006f0\n Call Trace:\n <IRQ>\n _raw_spin_lock_bh\n subflow_error_report\n mptcp_subflow_data_available\n __mptcp_move_skbs_from_subflow\n mptcp_data_ready\n tcp_data_queue\n tcp_rcv_established\n tcp_v4_do_rcv\n tcp_v4_rcv\n ip_protocol_deliver_rcu\n ip_local_deliver_finish\n __netif_receive_skb_one_core\n netif_receive_skb\n rtl8139_poll 8139too\n __napi_poll\n net_rx_action\n __do_softirq\n __irq_exit_rcu\n common_interrupt\n </IRQ>\n\nThe calling function - mptcp_subflow_data_available() - can be invoked\nfrom different contexts:\n- plain ssk socket lock\n- ssk socket lock + mptcp_data_lock\n- ssk socket lock + mptcp_data_lock + msk socket lock.\n\nSince subflow_error_report() tries to acquire the mptcp_data_lock, the\nlatter two call chains will cause soft lookup.\n\nThis change addresses the issue moving the error reporting call to\nouter functions, where the held locks list is known and the we can\nacquire only the needed one."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mptcp: corrige una b\u00fasqueda suave en subflow_error_report(). Maxim inform\u00f3 una b\u00fasqueda suave en subflow_error_report(): vigilancia: ERROR: bloqueo suave - \u00a1CPU#0 bloqueada durante 22 segundos! [swapper/0:0] RIP: 0010:native_queued_spin_lock_slowpath RSP: 0018:ffffa859c0003bc0 EFLAGS: 00000202 RAX: 0000000000000101 RBX: 0000000000000001 RCX: 000000000 0000000 RDX: ffff9195c2772d88 RSI: 0000000000000000 RDI: ffff9195c2772d88 RBP: ffff9195c2772d00 R08: 00000000000067b0 R09: c6e31da9eb1e44f4 :ffff9195ef379700 R11: ffff9195edb50710 R12: ffff9195c2772d88 R13: ffff9195f500e3d0 R14: ffff9195ef379700 R15: ffff9195ef379700 FS: 0000000000000000(0000) 1961f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c000407000 CR3: 0000000002988000 00000000000006f0 Seguimiento de llamadas: _raw_spin_lock_bh subflow_error_report mptcp_subflow_data_available __mptcp_move_skbs_from_subflow mptcp_data_ready tcp_data_queue tcp_rcv_establecido tcp_v4_do_rcv tcp_v4_rcv liver_rcu ip_local_deliver_finish __netif_receive_skb_one_core netif_receive_skb rtl8139_poll 8139too __napi_poll net_rx_action __do_softirq __irq_exit_rcu common_interrupt La funci\u00f3n de llamada, mptcp_subflow_data_available(), se puede invocar desde diferentes contextos: - enchufe ssk lock - bloqueo de socket ssk + mptcp_data_lock - bloqueo de socket ssk + mptcp_data_lock + bloqueo de socket msk. Dado que subflow_error_report() intenta adquirir mptcp_data_lock, las dos \u00faltimas cadenas de llamadas provocar\u00e1n una b\u00fasqueda suave. Este cambio soluciona el problema de mover la llamada de informe de errores a funciones externas, donde se conoce la lista de bloqueos retenidos y solo podemos adquirir el que necesitamos."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsch_cake: Fix out of bounds when parsing TCP options and header\n\nThe TCP option parser in cake qdisc (cake_get_tcpopt and\ncake_tcph_may_drop) could read one byte out of bounds. When the length\nis 1, the execution flow gets into the loop, reads one byte of the\nopcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads\none more byte, which exceeds the length of 1.\n\nThis fix is inspired by commit 9609dad263f8 (\"ipv4: tcp_input: fix stack\nout of bounds when parsing TCP options.\").\n\nv2 changes:\n\nAdded doff validation in cake_get_tcphdr to avoid parsing garbage as TCP\nheader. Although it wasn't strictly an out-of-bounds access (memory was\nallocated), garbage values could be read where CAKE expected the TCP\nheader if doff was smaller than 5."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: sch_cake: Correcci\u00f3n de l\u00edmites al analizar las opciones TCP y el encabezado. El analizador de opciones TCP en cake qdisc (cake_get_tcpopt y cake_tcph_may_drop) pod\u00eda leer un byte fuera de los l\u00edmites. Cuando la longitud es 1, el flujo de ejecuci\u00f3n entra en el bucle, lee un byte del c\u00f3digo de operaci\u00f3n y, si el c\u00f3digo de operaci\u00f3n no es TCPOPT_EOL ni TCPOPT_NOP, lee un byte m\u00e1s, que excede la longitud de 1. Esta soluci\u00f3n est\u00e1 inspirada en la confirmaci\u00f3n. 9609dad263f8 (\"ipv4: tcp_input: corrige la pila fuera de los l\u00edmites al analizar las opciones de TCP\"). Cambios en v2: Se agreg\u00f3 validaci\u00f3n de doff en cake_get_tcphdr para evitar analizar basura como encabezado TCP. Aunque no era estrictamente un acceso fuera de los l\u00edmites (se asign\u00f3 memoria), se pod\u00edan leer valores basura donde CAKE esperaba el encabezado TCP si doff era menor que 5."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: Fix out of bounds when parsing TCP options\n\nThe TCP option parser in mptcp (mptcp_get_options) could read one byte\nout of bounds. When the length is 1, the execution flow gets into the\nloop, reads one byte of the opcode, and if the opcode is neither\nTCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the\nlength of 1.\n\nThis fix is inspired by commit 9609dad263f8 (\"ipv4: tcp_input: fix stack\nout of bounds when parsing TCP options.\")."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mptcp: correcci\u00f3n de l\u00edmites al analizar opciones TCP. El analizador de opciones TCP en mptcp (mptcp_get_options) podr\u00eda leer un byte fuera de los l\u00edmites. Cuando la longitud es 1, el flujo de ejecuci\u00f3n entra en el bucle, lee un byte del c\u00f3digo de operaci\u00f3n y, si el c\u00f3digo de operaci\u00f3n no es TCPOPT_EOL ni TCPOPT_NOP, lee un byte m\u00e1s, que excede la longitud de 1. Esta soluci\u00f3n est\u00e1 inspirada en la confirmaci\u00f3n. 9609dad263f8 (\"ipv4: tcp_input: corrige la pila fuera de los l\u00edmites al analizar las opciones de TCP\")."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: synproxy: Fix out of bounds when parsing TCP options\n\nThe TCP option parser in synproxy (synproxy_parse_options) could read\none byte out of bounds. When the length is 1, the execution flow gets\ninto the loop, reads one byte of the opcode, and if the opcode is\nneither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds\nthe length of 1.\n\nThis fix is inspired by commit 9609dad263f8 (\"ipv4: tcp_input: fix stack\nout of bounds when parsing TCP options.\").\n\nv2 changes:\n\nAdded an early return when length < 0 to avoid calling\nskb_header_pointer with negative length."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: netfilter: synproxy: correcci\u00f3n de l\u00edmites al analizar opciones TCP. El analizador de opciones TCP en synproxy (synproxy_parse_options) podr\u00eda leer un byte fuera de los l\u00edmites. Cuando la longitud es 1, el flujo de ejecuci\u00f3n entra en el bucle, lee un byte del c\u00f3digo de operaci\u00f3n y, si el c\u00f3digo de operaci\u00f3n no es TCPOPT_EOL ni TCPOPT_NOP, lee un byte m\u00e1s, que excede la longitud de 1. Esta soluci\u00f3n est\u00e1 inspirada en la confirmaci\u00f3n. 9609dad263f8 (\"ipv4: tcp_input: corrige la pila fuera de los l\u00edmites al analizar las opciones de TCP\"). Cambios en v2: se agreg\u00f3 un retorno anticipado cuando la longitud <0 para evitar llamar a skb_header_pointer con una longitud negativa."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix page reclaim for dead peer hairpin\n\nWhen adding a hairpin flow, a firmware-side send queue is created for\nthe peer net device, which claims some host memory pages for its\ninternal ring buffer. If the peer net device is removed/unbound before\nthe hairpin flow is deleted, then the send queue is not destroyed which\nleads to a stack trace on pci device remove:\n\n[ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): MANAGE_PAGES(0x108) timeout. Will cause a leak of a command resource\n[ 748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): failed reclaiming pages: err -110\n[ 748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): failed reclaiming pages (-110) for func id 0x0\n[ 748.002171] ------------[ cut here ]------------\n[ 748.001177] FW pages counter is 4 after reclaiming all pages\n[ 748.001186] WARNING: CPU: 1 PID: 12985 at drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ +0.002771] Modules linked in: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [last unloaded: pps_core]\n[ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1\n[ 748.001376] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[ 748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core]\n[ 748.001679] Code: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 <0f> 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9\n[ 748.003781] RSP: 0018:ffff88815220faf8 EFLAGS: 00010286\n[ 748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000\n[ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102a441f51\n[ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8\n[ 748.001446] R10: ffff8882a50af73b R11: ffffed1054a15ee7 R12: fffffbfff07c1e30\n[ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000\n[ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) knlGS:0000000000000000\n[ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4: 0000000000370ea0\n[ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 748.001654] Call Trace:\n[ 748.000576] ? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core]\n[ 748.001416] ? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core]\n[ 748.001354] ? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core]\n[ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core]\n[ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core]\n[ 748.001200] remove_one+0x5f/0xc0 [mlx5_core]\n[ 748.001075] pci_device_remove+0x9f/0x1d0\n[ 748.000833] device_release_driver_internal+0x1e0/0x490\n[ 748.001207] unbind_store+0x19f/0x200\n[ 748.000942] ? sysfs_file_ops+0x170/0x170\n[ 748.001000] kernfs_fop_write_iter+0x2bc/0x450\n[ 748.000970] new_sync_write+0x373/0x610\n[ 748.001124] ? new_sync_read+0x600/0x600\n[ 748.001057] ? lock_acquire+0x4d6/0x700\n[ 748.000908] ? lockdep_hardirqs_on_prepare+0x400/0x400\n[ 748.001126] ? fd_install+0x1c9/0x4d0\n[ 748.000951] vfs_write+0x4d0/0x800\n[ 748.000804] ksys_write+0xf9/0x1d0\n[ 748.000868] ? __x64_sys_read+0xb0/0xb0\n[ 748.000811] ? filp_open+0x50/0x50\n[ 748.000919] ? syscall_enter_from_user_mode+0x1d/0x50\n[ 748.001223] do_syscall_64+0x3f/0x80\n[ 748.000892] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 748.00\n---truncated---"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net/mlx5e: Reparar la recuperaci\u00f3n de p\u00e1gina para la horquilla del par inactiva. Al agregar un flujo de horquilla, se crea una cola de env\u00edo del lado del firmware para el dispositivo de red del par, que reclama algunas p\u00e1ginas de memoria del host para su buffer de anillo interno. Si el dispositivo peer net se elimina/desvincula antes de eliminar el flujo de horquilla, entonces la cola de env\u00edo no se destruye, lo que genera un seguimiento de la pila en la eliminaci\u00f3n del dispositivo pci: [ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): Tiempo de espera de MANAGE_PAGES(0x108). Provocar\u00e1 una fuga de un recurso de comando [748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): error al recuperar p\u00e1ginas: err -110 [748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): error al recuperar p\u00e1ginas (-110) para el ID de funci\u00f3n 0x0 [748.002171] ------------[ cortar aqu\u00ed ]------------ [ 748.001177] p\u00e1ginas FW el contador es 4 despu\u00e9s de reclamar todas las p\u00e1ginas [748.001186] ADVERTENCIA: CPU: 1 PID: 12985 en drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [+0.002771] M\u00f3dulos vinculados en: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [\u00faltima descarga: pps_core] [ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1 [ 748.001376] Nombre del hardware: PC est\u00e1ndar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [748.001679] C\u00f3digo: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 <0f> 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9 [ 748.003781] RSP: 0018:ffff88815220faf8 GS: 00010286 [748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000 [ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: a441f51 [ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8 [ 748.001446] R10: ffff8882a50af73b R11: ee7 R12: ffffbfff07c1e30 [ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000 [ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) 000000000000 [ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4 : 0000000000370ea0 [ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [748.001654] Seguimiento de llamadas: [748.000576]? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core] [748.001416]? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core] [748.001354]? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core] [ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core] [ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core] [ 748.001200] uno+0x5f/0xc0 [mlx5_core] [ 748.001075] pci_device_remove+0x9f/0x1d0 [ 748.000833] device_release_driver_internal+0x1e0/0x490 [ 748.001207] unbind_store+0x19f/0x200 [ 748.000942] ? sysfs_file_ops+0x170/0x170 [ 748.001000] kernfs_fop_write_iter+0x2bc/0x450 [ 748.000970] new_sync_write+0x373/0x610 [ 748.001124] ? new_sync_read+0x600/0x600 [748.001057]? lock_acquire+0x4d6/0x700 [748.000908]? lockdep_hardirqs_on_prepare+0x400/0x400 [748.001126]? fd_install+0x1c9/0x4d0 [ 748.000951] vfs_write+0x4d0/0x800 [ 748.000804] ksys_write+0xf9/0x1d0 [ 748.000868] ? __x64_sys_read+0xb0/0xb0 [748.000811]? filp_open+0x50/0x50 [748.000919]? syscall_enter_from_user_mode+0x1d/0x50 [ 748.001223] do_syscall_64+0x3f/0x80 [ 748.000892] Entry_SYSCALL_64_after_hwframe+0x44/0xae [ 748.00 ---truncado---"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix use-after-free of encap entry in neigh update handler\n\nFunction mlx5e_rep_neigh_update() wasn't updated to accommodate rtnl lock\nremoval from TC filter update path and properly handle concurrent encap\nentry insertion/deletion which can lead to following use-after-free:\n\n [23827.464923] ==================================================================\n [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635\n [23827.472251]\n [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5\n [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]\n [23827.476731] Call Trace:\n [23827.477260] dump_stack+0xbb/0x107\n [23827.477906] print_address_description.constprop.0+0x18/0x140\n [23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.480905] kasan_report.cold+0x7c/0xd8\n [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.482744] kasan_check_range+0x145/0x1a0\n [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core]\n [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core]\n [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core]\n [23827.497486] ? read_word_at_a_time+0xe/0x20\n [23827.498250] ? strscpy+0xa0/0x2a0\n [23827.498889] process_one_work+0x8ac/0x14e0\n [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400\n [23827.500537] ? pwq_dec_nr_in_flight+0x2c0/0x2c0\n [23827.501359] ? rwlock_bug.part.0+0x90/0x90\n [23827.502116] worker_thread+0x53b/0x1220\n [23827.502831] ? process_one_work+0x14e0/0x14e0\n [23827.503627] kthread+0x328/0x3f0\n [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40\n [23827.505065] ? __kthread_bind_mask+0x90/0x90\n [23827.505912] ret_from_fork+0x1f/0x30\n [23827.506621]\n [23827.506987] Allocated by task 28248:\n [23827.507694] kasan_save_stack+0x1b/0x40\n [23827.508476] __kasan_kmalloc+0x7c/0x90\n [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core]\n [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core]\n [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core]\n [23827.512234] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core]\n [23827.513298] tc_setup_cb_add+0x1d5/0x420\n [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower]\n [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower]\n [23827.515821] tc_new_tfilter+0x89a/0x2070\n [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0\n [23827.517300] netlink_rcv_skb+0x11d/0x340\n [23827.518021] netlink_unicast+0x42b/0x700\n [23827.518742] netlink_sendmsg+0x743/0xc20\n [23827.519467] sock_sendmsg+0xb2/0xe0\n [23827.520131] ____sys_sendmsg+0x590/0x770\n [23827.520851] ___sys_sendmsg+0xd8/0x160\n [23827.521552] __sys_sendmsg+0xb7/0x140\n [23827.522238] do_syscall_64+0x3a/0x70\n [23827.522907] entry_SYSCALL_64_after_hwframe+0x44/0xae\n [23827.523797]\n [23827.524163] Freed by task 25948:\n [23827.524780] kasan_save_stack+0x1b/0x40\n [23827.525488] kasan_set_track+0x1c/0x30\n [23827.526187] kasan_set_free_info+0x20/0x30\n [23827.526968] __kasan_slab_free+0xed/0x130\n [23827.527709] slab_free_freelist_hook+0xcf/0x1d0\n [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0\n [23827.529317] kfree_rcu_work+0x55f/0xb70\n [23827.530024] process_one_work+0x8ac/0x14e0\n [23827.530770] worker_thread+0x53b/0x1220\n [23827.531480] kthread+0x328/0x3f0\n [23827.532114] ret_from_fork+0x1f/0x30\n [23827.532785]\n [23827.533147] Last potentially related work creation:\n [23827.534007] kasan_save_stack+0x1b/0x40\n [23827.534710] kasan_record_aux_stack+0xab/0xc0\n [23827.535492] kvfree_call_rcu+0x31/0x7b0\n [23827.536206] mlx5e_tc_del\n---truncated---"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net/mlx5e: se corrigi\u00f3 el use after free de la entrada encap en el controlador de actualizaci\u00f3n cercano. La funci\u00f3n mlx5e_rep_neigh_update() no se actualiz\u00f3 para permitir la eliminaci\u00f3n del bloqueo rtnl de la ruta de actualizaci\u00f3n del filtro TC y manejar adecuadamente inserci\u00f3n/eliminaci\u00f3n simult\u00e1nea de entradas encapsuladas que pueden conducir al siguiente use after free: [23827.464923] ================================ ==================================== [23827.469446] BUG: KASAN: use after free en mlx5e_encap_take +0x72/0x140 [mlx5_core] [23827.470971] Lectura de tama\u00f1o 4 en la direcci\u00f3n ffff8881d132228c por tarea kworker/u20:6/21635 [23827.472251] [23827.472615] CPU: 9 PID: 21635 kworker/u20 :6 No contaminado 5.13.0 -rc3+ #5 [23827.473788] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [23827.475639] Cola de trabajo: mlx5e mlx5e_rep_neigh_update [ mlx5_core] [23827.476731] Seguimiento de llamadas: [23827.477260] dump_stack+0xbb/0x107 [23827.477906] print_address_description.constprop.0+0x18/0x140 [23827.478896]? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.480905] kasan_report.cold+0x7c/0xd8 [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.482744] kasan_check_range+0x145/0x1a0 [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core] [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core] [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core] [23827.497486] ? read_word_at_a_time+0xe/0x20 [23827.498250] ? strscpy+0xa0/0x2a0 [23827.498889] process_one_work+0x8ac/0x14e0 [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400 [23827.500537]? pwq_dec_nr_in_flight+0x2c0/0x2c0 [23827.501359] ? rwlock_bug.part.0+0x90/0x90 [23827.502116] worker_thread+0x53b/0x1220 [23827.502831]? Process_one_work+0x14e0/0x14e0 [23827.503627] kthread+0x328/0x3f0 [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40 [23827.505065] ? __kthread_bind_mask+0x90/0x90 [23827.505912] ret_from_fork+0x1f/0x30 [23827.506621] [23827.506987] Asignado por tarea 28248: [23827.507694] 0 [23827.508476] __kasan_kmalloc+0x7c/0x90 [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core ] [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core] [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core] [23827.512234] 191c/0x4870 [mlx5_core] [23827.513298] tc_setup_cb_add+0x1d5/0x420 [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower] [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower] [23827.515821] tc_new_tfilter+0x89a/0x2070 [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0 [23827.51 7300] netlink_rcv_skb+0x11d/0x340 [23827.518021] netlink_unicast+0x42b/0x700 [23827.518742] netlink_sendmsg +0x743/0xc20 [23827.519467] sock_sendmsg+0xb2/0xe0 [23827.520131] ____sys_sendmsg+0x590/0x770 [23827.520851] ___sys_sendmsg+0xd8/0x160 [23827. 521552] __sys_sendmsg+0xb7/0x140 [23827.522238] do_syscall_64+0x3a/0x70 [23827.522907] Entry_SYSCALL_64_after_hwframe+0x44 /0xae [23827.523797] [23827.524163] Liberado por la tarea 25948: [23827.524780] kasan_save_stack+0x1b/0x40 [23827.525488] kasan_set_track+0x1c/0x30 [23827.526187] _free_info+0x20/0x30 [23827.526968] __kasan_slab_free+0xed/0x130 [23827.527709] slab_free_freelist_hook+ 0xcf/0x1d0 [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0 [23827.529317] kfree_rcu_work+0x55f/0xb70 [23827.530024] Process_one_work+0x8ac/0x14e0 [23827.530770 ] work_thread+0x53b/0x1220 [23827.531480] kthread+0x328/0x3f0 [23827.532114] ret_from_fork+0x1f/ 0x30 [23827.532785] [23827.533147] \u00daltima creaci\u00f3n de trabajo potencialmente relacionado: [23827.534007] kasan_save_stack+0x1b/0x40 [23827.534710] kasan_record_aux_stack+0xab/0xc0 [23827.535492] _rcu+0x31/0x7b0 [23827.536206] mlx5e_tc_del ---truncado---"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nudp: fix race between close() and udp_abort()\n\nKaustubh reported and diagnosed a panic in udp_lib_lookup().\nThe root cause is udp_abort() racing with close(). Both\nracing functions acquire the socket lock, but udp{v6}_destroy_sock()\nrelease it before performing destructive actions.\n\nWe can't easily extend the socket lock scope to avoid the race,\ninstead use the SOCK_DEAD flag to prevent udp_abort from doing\nany action when the critical race happens.\n\nDiagnosed-and-tested-by: Kaustubh Pandey <kapandey@codeaurora.org>"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: udp: corrige la ejecuci\u00f3n entre close() y udp_abort(). Kaustubh inform\u00f3 y diagnostic\u00f3 un p\u00e1nico en udp_lib_lookup(). La causa principal es que udp_abort() compite con close(). Ambas funciones de ejecuci\u00f3n adquieren el bloqueo del socket, pero udp{v6}_destroy_sock() lo libera antes de realizar acciones destructivas. No podemos extender f\u00e1cilmente el alcance del bloqueo del socket para evitar la ejecuci\u00f3n; en su lugar, usamos el indicador SOCK_DEAD para evitar que udp_abort realice alguna acci\u00f3n cuando ocurre la ejecuci\u00f3n cr\u00edtica. Diagnosticado y probado por: Kaustubh Pandey "
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: rds: fix memory leak in rds_recvmsg\n\nSyzbot reported memory leak in rds. The problem\nwas in unputted refcount in case of error.\n\nint rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,\n\t\tint msg_flags)\n{\n...\n\n\tif (!rds_next_incoming(rs, &inc)) {\n\t\t...\n\t}\n\nAfter this \"if\" inc refcount incremented and\n\n\tif (rds_cmsg_recv(inc, msg, rs)) {\n\t\tret = -EFAULT;\n\t\tgoto out;\n\t}\n...\nout:\n\treturn ret;\n}\n\nin case of rds_cmsg_recv() fail the refcount won't be\ndecremented. And it's easy to see from ftrace log, that\nrds_inc_addref() don't have rds_inc_put() pair in\nrds_recvmsg() after rds_cmsg_recv()\n\n 1) | rds_recvmsg() {\n 1) 3.721 us | rds_inc_addref();\n 1) 3.853 us | rds_message_inc_copy_to_user();\n 1) + 10.395 us | rds_cmsg_recv();\n 1) + 34.260 us | }"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:rds: corrige p\u00e9rdida de memoria en rds_recvmsg. Syzbot inform\u00f3 p\u00e9rdida de memoria en rds. El problema estaba en el recuento no puesto en caso de error. int rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, int msg_flags) { ... if (!rds_next_incoming(rs, &inc)) { ... } Despu\u00e9s de esto \"if\" inc refcount incrementado y if (rds_cmsg_recv (inc, mensaje, rs)) { ret = -EFAULT; salir; } ... fuera: devolver ret; } en caso de que rds_cmsg_recv() falle, el recuento no disminuir\u00e1. Y es f\u00e1cil ver en el registro de ftrace que rds_inc_addref() no tiene el par rds_inc_put() en rds_recvmsg() despu\u00e9s de rds_cmsg_recv() 1) | rds_recvmsg() { 1) 3.721 us| rds_inc_addref(); 1) 3.853 us| rds_message_inc_copy_to_user(); 1) + 10.395 us| rds_cmsg_recv(); 1) + 34.260 us| }"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv4: fix memory leak in netlbl_cipsov4_add_std\n\nReported by syzkaller:\nBUG: memory leak\nunreferenced object 0xffff888105df7000 (size 64):\ncomm \"syz-executor842\", pid 360, jiffies 4294824824 (age 22.546s)\nhex dump (first 32 bytes):\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\nbacktrace:\n[<00000000e67ed558>] kmalloc include/linux/slab.h:590 [inline]\n[<00000000e67ed558>] kzalloc include/linux/slab.h:720 [inline]\n[<00000000e67ed558>] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [inline]\n[<00000000e67ed558>] netlbl_cipsov4_add+0x390/0x2340 net/netlabel/netlabel_cipso_v4.c:416\n[<0000000006040154>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739\n[<00000000204d7a1c>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n[<00000000204d7a1c>] genl_rcv_msg+0x2bf/0x4f0 net/netlink/genetlink.c:800\n[<00000000c0d6a995>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504\n[<00000000d78b9d2c>] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811\n[<000000009733081b>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]\n[<000000009733081b>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340\n[<00000000d5fd43b8>] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929\n[<000000000a2d1e40>] sock_sendmsg_nosec net/socket.c:654 [inline]\n[<000000000a2d1e40>] sock_sendmsg+0x139/0x170 net/socket.c:674\n[<00000000321d1969>] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350\n[<00000000964e16bc>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404\n[<000000001615e288>] __sys_sendmsg+0xd3/0x190 net/socket.c:2433\n[<000000004ee8b6a5>] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47\n[<00000000171c7cee>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe memory of doi_def->map.std pointing is allocated in\nnetlbl_cipsov4_add_std, but no place has freed it. It should be\nfreed in cipso_v4_doi_free which frees the cipso DOI resource."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv4: corrige la p\u00e9rdida de memoria en netlbl_cipsov4_add_std. Reportado por syzkaller: BUG: p\u00e9rdida de memoria objeto sin referencia 0xffff888105df7000 (tama\u00f1o 64): comm \"syz-executor842\", pid 360, jiffies 4294824824 ( edad 22,546 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000e67ed558>] kmalloc include/linux/slab.h:590 [en l\u00ednea] [<00000000e67ed558> ] kzalloc include/linux/slab.h:720 [en l\u00ednea] [<00000000e67ed558>] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [en l\u00ednea] [<00000000e67ed558>] netlbl_cipsov4_add+0x390/0x234 0 net/netlabel/netlabel_cipso_v4.c: 416 [<0000000006040154>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739 [<00000000204d7a1c>] genl_family_rcv_msg net/netlink/genetlink.c:783 [en l\u00ednea] 00000204d7a1c>] genl_rcv_msg+0x2bf /0x4f0 net/netlink/genetlink.c:800 [<00000000c0d6a995>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504 [<00000000d78b9d2c>] genl_rcv+0x24/0x40 11 [ <000000009733081b>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [en l\u00ednea] [<000000009733081b>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340 [<00000000d5fd43b8>] enviar mensaje+0x789/0xc70 net/netlink/ af_netlink.c:1929 [<000000000a2d1e40>] sock_sendmsg_nosec net/socket.c:654 [en l\u00ednea] [<000000000a2d1e40>] sock_sendmsg+0x139/0x170 net/socket.c:674 [<00000000321d19 69>] ____sys_sendmsg+0x658/0x7d0 neto/ socket.c:2350 [<00000000964e16bc>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404 [<000000001615e288>] __sys_sendmsg+0xd3/0x190 net/socket.c:2433 4ee8b6a5>] do_syscall_64+0x37/0x90 arco /x86/entry/common.c:47 [<00000000171c7cee>] Entry_SYSCALL_64_after_hwframe+0x44/0xae La memoria de apuntamiento doi_def->map.std est\u00e1 asignada en netlbl_cipsov4_add_std, pero no se ha liberado ning\u00fan lugar. Debe liberarse en cipso_v4_doi_free, lo que libera el recurso cipso DOI."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: fix skb length check in ieee80211_scan_rx()\n\nReplace hard-coded compile-time constants for header length check\nwith dynamic determination based on the frame type. Otherwise, we\nhit a validation WARN_ON in cfg80211 later.\n\n[style fixes, reword commit message]"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mac80211: corrige la verificaci\u00f3n de longitud de skb en ieee80211_scan_rx() Reemplace las constantes de tiempo de compilaci\u00f3n codificadas para la verificaci\u00f3n de la longitud del encabezado con determinaci\u00f3n din\u00e1mica basada en el tipo de trama. De lo contrario, obtendremos un WARN_ON de validaci\u00f3n en cfg80211 m\u00e1s adelante. [correcciones de estilo, reformular mensaje de confirmaci\u00f3n]"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Avoid WARN_ON timing related checks\n\nThe soft/batadv interface for a queued OGM can be changed during the time\nthe OGM was queued for transmission and when the OGM is actually\ntransmitted by the worker.\n\nBut WARN_ON must be used to denote kernel bugs and not to print simple\nwarnings. A warning can simply be printed using pr_warn."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: batman-adv: Evite comprobaciones relacionadas con el tiempo WARN_ON. La interfaz soft/batadv para un MDS en cola se puede cambiar durante el tiempo que el MDS estuvo en cola para transmisi\u00f3n y cuando el MDS realmente se transmite por el trabajador. Pero WARN_ON debe usarse para indicar errores del kernel y no para imprimir simples advertencias. Una advertencia se puede imprimir simplemente usando pr_warn."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix potential memory leak in DMUB hw_init\n\n[Why]\nOn resume we perform DMUB hw_init which allocates memory:\ndm_resume->dm_dmub_hw_init->dc_dmub_srv_create->kzalloc\nThat results in memory leak in suspend/resume scenarios.\n\n[How]\nAllocate memory for the DC wrapper to DMUB only if it was not\nallocated before.\nNo need to reallocate it on suspend/resume."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige una posible p\u00e9rdida de memoria en DMUB hw_init [Por qu\u00e9] Al reanudar ejecutamos DMUB hw_init que asigna memoria: dm_resume->dm_dmub_hw_init->dc_dmub_srv_create->kzalloc Eso resulta en p\u00e9rdida de memoria en escenarios de suspensi\u00f3n/reanudaci\u00f3n. [C\u00f3mo] Asigne memoria para el contenedor DC a DMUB solo si no se asign\u00f3 antes. No es necesario reasignarlo al suspender/reanudar."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix use-after-free in gfs2_glock_shrink_scan\n\nThe GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to\nremove the glock from the lru list in __gfs2_glock_put().\n\nOn the shrink scan path, the same flag is cleared under lru_lock but because\nof cond_resched_lock(&lru_lock) in gfs2_dispose_glock_lru(), progress on the\nput side can be made without deleting the glock from the lru list.\n\nKeep GLF_LRU across the race window opened by cond_resched_lock(&lru_lock) to\nensure correct behavior on both sides - clear GLF_LRU after list_del under\nlru_lock."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: corrige use-after-free en gfs2_glock_shrink_scan. El indicador GLF_LRU se marca en lru_lock en gfs2_glock_remove_from_lru() para eliminar el glock de la lista lru en __gfs2_glock_put(). En la ruta de escaneo de reducci\u00f3n, la misma bandera se borra en lru_lock pero debido a cond_resched_lock(&lru_lock) en gfs2_dispose_glock_lru(), se puede avanzar en el lado de venta sin eliminar la glock de la lista de lru. Mantenga GLF_LRU en la ventana de ejecuci\u00f3n abierta por cond_resched_lock(&lru_lock) para garantizar un comportamiento correcto en ambos lados; borre GLF_LRU despu\u00e9s de list_del en lru_lock."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nkvm: LAPIC: Restore guard to prevent illegal APIC register access\n\nPer the SDM, \"any access that touches bytes 4 through 15 of an APIC\nregister may cause undefined behavior and must not be executed.\"\nWorse, such an access in kvm_lapic_reg_read can result in a leak of\nkernel stack contents. Prior to commit 01402cf81051 (\"kvm: LAPIC:\nwrite down valid APIC registers\"), such an access was explicitly\ndisallowed. Restore the guard that was removed in that commit."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kvm: LAPIC: Restaurar protecci\u00f3n para evitar el acceso ilegal al registro APIC. Seg\u00fan el SDM, \"cualquier acceso que toque los bytes 4 al 15 de un registro APIC puede causar un comportamiento indefinido y no debe ejecutarse \". Peor a\u00fan, dicho acceso en kvm_lapic_reg_read puede resultar en una fuga del contenido de la pila del kernel. Antes de confirmar 01402cf81051 (\"kvm: LAPIC: anotar registros APIC v\u00e1lidos\"), dicho acceso se prohib\u00eda expl\u00edcitamente. Restaura la guardia que se elimin\u00f3 en esa confirmaci\u00f3n."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: make sure wait for page writeback in memory_failure\n\nOur syzkaller trigger the \"BUG_ON(!list_empty(&inode->i_wb_list))\" in\nclear_inode:\n\n kernel BUG at fs/inode.c:519!\n Internal error: Oops - BUG: 0 [#1] SMP\n Modules linked in:\n Process syz-executor.0 (pid: 249, stack limit = 0x00000000a12409d7)\n CPU: 1 PID: 249 Comm: syz-executor.0 Not tainted 4.19.95\n Hardware name: linux,dummy-virt (DT)\n pstate: 80000005 (Nzcv daif -PAN -UAO)\n pc : clear_inode+0x280/0x2a8\n lr : clear_inode+0x280/0x2a8\n Call trace:\n clear_inode+0x280/0x2a8\n ext4_clear_inode+0x38/0xe8\n ext4_free_inode+0x130/0xc68\n ext4_evict_inode+0xb20/0xcb8\n evict+0x1a8/0x3c0\n iput+0x344/0x460\n do_unlinkat+0x260/0x410\n __arm64_sys_unlinkat+0x6c/0xc0\n el0_svc_common+0xdc/0x3b0\n el0_svc_handler+0xf8/0x160\n el0_svc+0x10/0x218\n Kernel panic - not syncing: Fatal exception\n\nA crash dump of this problem show that someone called __munlock_pagevec\nto clear page LRU without lock_page: do_mmap -> mmap_region -> do_munmap\n-> munlock_vma_pages_range -> __munlock_pagevec.\n\nAs a result memory_failure will call identify_page_state without\nwait_on_page_writeback. And after truncate_error_page clear the mapping\nof this page. end_page_writeback won't call sb_clear_inode_writeback to\nclear inode->i_wb_list. That will trigger BUG_ON in clear_inode!\n\nFix it by checking PageWriteback too to help determine should we skip\nwait_on_page_writeback."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/memory-failure: aseg\u00farese de esperar la reescritura de la p\u00e1gina en Memory_failure. Nuestro syzkaller activa el \"BUG_ON(!list_empty(&inode->i_wb_list))\" en clear_inode: kernel BUG en fs /inodo.c:519! Error interno: Oops - BUG: 0 [#1] M\u00f3dulos SMP vinculados en: Proceso syz-executor.0 (pid: 249, l\u00edmite de pila = 0x00000000a12409d7) CPU: 1 PID: 249 Comm: syz-executor.0 No contaminado 4.19. 95 Nombre de hardware: linux,dummy-virt (DT) pstate: 80000005 (Nzcv daif -PAN -UAO) pc: clear_inode+0x280/0x2a8 lr: clear_inode+0x280/0x2a8 Rastreo de llamadas: clear_inode+0x280/0x2a8 ext4_clear_inode+0x38/0xe8 ext4_free_inode+0x130/0xc68 ext4_evict_inode+0xb20/0xcb8 desalojar+0x1a8/0x3c0 iput+0x344/0x460 do_unlinkat+0x260/0x410 __arm64_sys_unlinkat+0x6c/0xc0 el0_svc_common+0xdc /0x3b0 el0_svc_handler+0xf8/0x160 el0_svc+0x10/0x218 P\u00e1nico del kernel: no se sincroniza : Excepci\u00f3n fatal Un volcado de memoria de este problema muestra que alguien llam\u00f3 a __munlock_pagevec para borrar la p\u00e1gina LRU sin lock_page: do_mmap -> mmap_region -> do_munmap -> munlock_vma_pages_range -> __munlock_pagevec. Como resultado, Memory_failure llamar\u00e1 a identify_page_state sin wait_on_page_writeback. Y despu\u00e9s de truncate_error_page, borre el mapeo de esta p\u00e1gina. end_page_writeback no llamar\u00e1 a sb_clear_inode_writeback para borrar inode->i_wb_list. \u00a1Eso activar\u00e1 BUG_ON en clear_inode! Solucionarlo marcando tambi\u00e9n PageWriteback para ayudar a determinar si debemos omitir wait_on_page_writeback."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ieee802154: fix null deref in parse dev addr\n\nFix a logic error that could result in a null deref if the user sets\nthe mode incorrectly for the given addr type."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net: ieee802154: corrige el deref null en analizar dev addr. Se corrige un error l\u00f3gico que podr\u00eda resultar en un deref null si el usuario configura el modo incorrectamente para el tipo de direcci\u00f3n dado."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Fix error handling of scsi_host_alloc()\n\nAfter device is initialized via device_initialize(), or its name is set via\ndev_set_name(), the device has to be freed via put_device(). Otherwise\ndevice name will be leaked because it is allocated dynamically in\ndev_set_name().\n\nFix the leak by replacing kfree() with put_device(). Since\nscsi_host_dev_release() properly handles IDA and kthread removal, remove\nspecial-casing these from the error handling as well."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: corrige el manejo de errores de scsi_host_alloc(). Despu\u00e9s de que el dispositivo se inicializa mediante device_initialize(), o su nombre se establece mediante dev_set_name(), el dispositivo debe liberarse mediante put_device (). De lo contrario, se filtrar\u00e1 el nombre del dispositivo porque se asigna din\u00e1micamente en dev_set_name(). Solucione la fuga reemplazando kfree() con put_device(). Dado que scsi_host_dev_release() maneja adecuadamente la eliminaci\u00f3n de IDA y kthread, elimine tambi\u00e9n estas may\u00fasculas y min\u00fasculas especiales del manejo de errores."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix use-after-free in nfs4_init_client()\n\nKASAN reports a use-after-free when attempting to mount two different\nexports through two different NICs that belong to the same server.\n\nOlga was able to hit this with kernels starting somewhere between 5.7\nand 5.10, but I traced the patch that introduced the clear_bit() call to\n4.13. So something must have changed in the refcounting of the clp\npointer to make this call to nfs_put_client() the very last one."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: corrige el manejo de errores de scsi_host_alloc(). Despu\u00e9s de que el dispositivo se inicializa mediante device_initialize(), o su nombre se establece mediante dev_set_name(), el dispositivo debe liberarse mediante put_device (). De lo contrario, se filtrar\u00e1 el nombre del dispositivo porque se asigna din\u00e1micamente en dev_set_name(). Solucione la fuga reemplazando kfree() con put_device(). Dado que scsi_host_dev_release() maneja adecuadamente la eliminaci\u00f3n de IDA y kthread, elimine tambi\u00e9n estas may\u00fasculas y min\u00fasculas especiales del manejo de errores."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a potential NULL dereference in nfs_get_client()\n\nNone of the callers are expecting NULL returns from nfs_get_client() so\nthis code will lead to an Oops. It's better to return an error\npointer. I expect that this is dead code so hopefully no one is\naffected."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: NFS: corrija una posible desreferencia NULL en nfs_get_client() Ninguna de las personas que llaman espera retornos NULL de nfs_get_client(), por lo que este c\u00f3digo generar\u00e1 un error \u00a1Oops! Es mejor devolver un puntero de error. Supongo que se trata de un c\u00f3digo inactivo, as\u00ed que espero que nadie se vea afectado."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix initializing CQ fragments buffer\n\nThe function init_cq_frag_buf() can be called to initialize the current CQ\nfragments buffer cq->buf, or the temporary cq->resize_buf that is filled\nduring CQ resize operation.\n\nHowever, the offending commit started to use function get_cqe() for\ngetting the CQEs, the issue with this change is that get_cqe() always\nreturns CQEs from cq->buf, which leads us to initialize the wrong buffer,\nand in case of enlarging the CQ we try to access elements beyond the size\nof the current cq->buf and eventually hit a kernel panic.\n\n [exception RIP: init_cq_frag_buf+103]\n [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib]\n [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core]\n [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt]\n [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt]\n [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt]\n [ffff9f799ddcbec8] kthread at ffffffffa66c5da1\n [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd\n\nFix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that\ntakes the correct source buffer as a parameter."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/mlx5: Correcci\u00f3n al inicializar el b\u00fafer de fragmentos CQ. Se puede llamar a la funci\u00f3n init_cq_frag_buf() para inicializar el b\u00fafer de fragmentos CQ actual cq->buf, o el cq->resize_buf temporal que es rellenado durante la operaci\u00f3n de cambio de tama\u00f1o de CQ. Sin embargo, la confirmaci\u00f3n infractora comenz\u00f3 a usar la funci\u00f3n get_cqe() para obtener los CQE, el problema con este cambio es que get_cqe() siempre devuelve CQE desde cq->buf, lo que nos lleva a inicializar el b\u00fafer incorrecto y, en caso de ampliarlo, En el CQ intentamos acceder a elementos m\u00e1s all\u00e1 del tama\u00f1o del cq->buf actual y finalmente entramos en p\u00e1nico en el kernel. [excepci\u00f3n RIP: init_cq_frag_buf+103] [ffff9f799ddcbcd8] mlx5_ib_resize_cq en fffffffc0835d60 [mlx5_ib] [ffff9f799ddcbdb0] ib_resize_cq en fffffffc05270df [ib_core] [ffff9f799ddcbdc0] _rdma_setup_qp en ffffffffc0a6a712 [llt] [ffff9f799ddcbe10] llt_rdma_cc_event_action en ffffffffc0a6b411 [llt] [ffff9f799ddcbe98] llt_rdma_client_conn_thread en ffffffffc0a6bb75 [llt] [ffff9f799ddcbec8] kthread en ffffffffa66c5da1 [ffff9f799ddcbf50] ret_from_fork_nospec_begin en ffffffffa6d95ddd Arr\u00e9glelo obteniendo el CQE necesario llamando a mlx5_frag_buf_get_wqe() que toma el b\u00fafer de origen correcto como par\u00e1metro."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Ensure liveliness of nested VM-Enter fail tracepoint message\n\nUse the __string() machinery provided by the tracing subystem to make a\ncopy of the string literals consumed by the \"nested VM-Enter failed\"\ntracepoint. A complete copy is necessary to ensure that the tracepoint\ncan't outlive the data/memory it consumes and deference stale memory.\n\nBecause the tracepoint itself is defined by kvm, if kvm-intel and/or\nkvm-amd are built as modules, the memory holding the string literals\ndefined by the vendor modules will be freed when the module is unloaded,\nwhereas the tracepoint and its data in the ring buffer will live until\nkvm is unloaded (or \"indefinitely\" if kvm is built-in).\n\nThis bug has existed since the tracepoint was added, but was recently\nexposed by a new check in tracing to detect exactly this type of bug.\n\n fmt: '%s%s\n ' current_buffer: ' vmx_dirty_log_t-140127 [003] .... kvm_nested_vmenter_failed: '\n WARNING: CPU: 3 PID: 140134 at kernel/trace/trace.c:3759 trace_check_vprintf+0x3be/0x3e0\n CPU: 3 PID: 140134 Comm: less Not tainted 5.13.0-rc1-ce2e73ce600a-req #184\n Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014\n RIP: 0010:trace_check_vprintf+0x3be/0x3e0\n Code: <0f> 0b 44 8b 4c 24 1c e9 a9 fe ff ff c6 44 02 ff 00 49 8b 97 b0 20\n RSP: 0018:ffffa895cc37bcb0 EFLAGS: 00010282\n RAX: 0000000000000000 RBX: ffffa895cc37bd08 RCX: 0000000000000027\n RDX: 0000000000000027 RSI: 00000000ffffdfff RDI: ffff9766cfad74f8\n RBP: ffffffffc0a041d4 R08: ffff9766cfad74f0 R09: ffffa895cc37bad8\n R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffc0a041d4\n R13: ffffffffc0f4dba8 R14: 0000000000000000 R15: ffff976409f2c000\n FS: 00007f92fa200740(0000) GS:ffff9766cfac0000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000559bd11b0000 CR3: 000000019fbaa002 CR4: 00000000001726e0\n Call Trace:\n trace_event_printf+0x5e/0x80\n trace_raw_output_kvm_nested_vmenter_failed+0x3a/0x60 [kvm]\n print_trace_line+0x1dd/0x4e0\n s_show+0x45/0x150\n seq_read_iter+0x2d5/0x4c0\n seq_read+0x106/0x150\n vfs_read+0x98/0x180\n ksys_read+0x5f/0xe0\n do_syscall_64+0x40/0xb0\n entry_SYSCALL_64_after_hwframe+0x44/0xae"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Garantizar la vivacidad de la VM anidada. Ingrese el mensaje de punto de seguimiento de falla. Utilice la maquinaria __string() proporcionada por el subsistema de seguimiento para hacer una copia de los literales de cadena consumidos por los puntos de seguimiento \"nested VM-Enter failed\". Es necesaria una copia completa para garantizar que el punto de seguimiento no pueda vivir m\u00e1s que los datos o la memoria que consume y para evitar la memoria obsoleta. Debido a que el punto de seguimiento en s\u00ed est\u00e1 definido por kvm, si kvm-intel y/o kvm-amd se construyen como m\u00f3dulos, la memoria que contiene los literales de cadena definidos por los m\u00f3dulos del proveedor se liberar\u00e1 cuando se descargue el m\u00f3dulo, mientras que el punto de seguimiento y sus datos en el b\u00fafer circular permanecer\u00e1 hasta que se descargue kvm (o \"indefinidamente\" si kvm est\u00e1 integrado). Este error ha existido desde que se agreg\u00f3 el punto de seguimiento, pero recientemente qued\u00f3 expuesto mediante una nueva verificaci\u00f3n en el seguimiento para detectar exactamente este tipo de error. fmt: '%s%s ' current_buffer: ' vmx_dirty_log_t-140127 [003] .... kvm_nested_vmenter_failed: ' ADVERTENCIA: CPU: 3 PID: 140134 en kernel/trace/trace.c:3759 trace_check_vprintf+0x3be/0x3e0 CPU: 3 PID: 140134 Comm: less No contaminado 5.13.0-rc1-ce2e73ce600a-req #184 Nombre de hardware: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014 RIP: 0010:trace_check_vprintf+0x3be/0x3e0 C\u00f3digo: < 0f> 0b 44 8b 4c 24 1c e9 a9 fe ff ff c6 44 02 ff 00 49 8b 97 b0 20 RSP: 0018:ffffa895cc37bcb0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: cc37bd08 RCX: 0000000000000027 RDX: 0000000000000027 RSI: 00000000ffffdfff RDI: ffff9766cfad74f8 RBP : ffffffffc0a041d4 R08: ffff9766cfad74f0 R09: ffffa895cc37bad8 R10: 0000000000000001 R11: 00000000000000001 R12: ffffffffc0a041d4 R13: ffffffffc0f4dba8 R 14: 0000000000000000 R15: ffff976409f2c000 FS: 00007f92fa200740(0000) GS:ffff9766cfac0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 00 CR0: 0000000080050033 CR2: 0000559bd11b0000 CR3: 000000019fbaa002 CR4: 00000000001726e0 Seguimiento de llamadas: trace_event_printf+0x5e/0x80 3a/0x60 [kvm] print_trace_line+0x1dd/0x4e0 s_show+0x45/0x150 seq_read_iter+0x2d5/0x4c0 seq_read+0x106/0x150 vfs_read+ 0x98/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x40/0xb0 entrada_SYSCALL_64_after_hwframe+0x44/0xae"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: wcd934x: Fix shift-out-of-bounds error\n\nbit-mask for pins 0 to 4 is BIT(0) to BIT(4) however we ended up with BIT(n - 1)\nwhich is not right, and this was caught by below usban check\n\nUBSAN: shift-out-of-bounds in drivers/gpio/gpio-wcd934x.c:34:14"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: gpio: wcd934x: correcci\u00f3n de error de desplazamiento fuera de los l\u00edmites. La m\u00e1scara de bits para los pines 0 a 4 es BIT(0) a BIT(4); sin embargo, terminamos con BIT( n - 1) lo cual no es correcto, y esto fue detectado por la siguiente verificaci\u00f3n USB UBSAN: shift-out-of-bounds in drivers/gpio/gpio-wcd934x.c:34:14"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Fix Null-point-dereference in fmt_single_name()\n\nCheck the return value of devm_kstrdup() in case of\nNull-point-dereference."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: core: corrige la desreferencia de punto nulo en fmt_single_name(). Verifique el valor de retorno de devm_kstrdup() en caso de dereferencia de punto nulo."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: Verify port when creating flow rule\n\nValidate port value provided by the user and with that remove no longer\nneeded validation by the driver. The missing check in the mlx5_ib driver\ncould cause to the below oops.\n\nCall trace:\n _create_flow_rule+0x2d4/0xf28 [mlx5_ib]\n mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]\n ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]\n ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]\n ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]\n ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]\n do_vfs_ioctl+0xd0/0xaf0\n ksys_ioctl+0x84/0xb4\n __arm64_sys_ioctl+0x28/0xc4\n el0_svc_common.constprop.3+0xa4/0x254\n el0_svc_handler+0x84/0xa0\n el0_svc+0x10/0x26c\n Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: RDMA: Verificar puerto al crear regla de flujo. Validar valor de puerto proporcionado por el usuario y con ello eliminar la validaci\u00f3n que ya no necesita el controlador. La verificaci\u00f3n que falta en el controlador mlx5_ib podr\u00eda provocar los siguientes errores. Seguimiento de llamadas: _create_flow_rule+0x2d4/0xf28 [mlx5_ib] mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib] ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x1 50 [ib_uverbs] ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs] ib_uverbs_ioctl+0x158 /0x1d0 [ib_uverbs] do_vfs_ioctl+0xd0/0xaf0 ksys_ioctl+0x84/0xb4 __arm64_sys_ioctl+0x28/0xc4 el0_svc_common.constprop.3+0xa4/0x254 el0_svc_handler+0x84/0xa0 0x10/0x26c C\u00f3digo: b9401260 f9615681 51000400 8b001c20 (f9403c1a)"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/ipoib: Fix warning caused by destroying non-initial netns\n\nAfter the commit 5ce2dced8e95 (\"RDMA/ipoib: Set rtnl_link_ops for ipoib\ninterfaces\"), if the IPoIB device is moved to non-initial netns,\ndestroying that netns lets the device vanish instead of moving it back to\nthe initial netns, This is happening because default_device_exit() skips\nthe interfaces due to having rtnl_link_ops set.\n\nSteps to reporoduce:\n ip netns add foo\n ip link set mlx5_ib0 netns foo\n ip netns delete foo\n\nWARNING: CPU: 1 PID: 704 at net/core/dev.c:11435 netdev_exit+0x3f/0x50\nModules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT\nnf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack\nnf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun d\n fuse\nCPU: 1 PID: 704 Comm: kworker/u64:3 Tainted: G S W 5.13.0-rc1+ #1\nHardware name: Dell Inc. PowerEdge R630/02C2CP, BIOS 2.1.5 04/11/2016\nWorkqueue: netns cleanup_net\nRIP: 0010:netdev_exit+0x3f/0x50\nCode: 48 8b bb 30 01 00 00 e8 ef 81 b1 ff 48 81 fb c0 3a 54 a1 74 13 48\n8b 83 90 00 00 00 48 81 c3 90 00 00 00 48 39 d8 75 02 5b c3 <0f> 0b 5b\nc3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00\nRSP: 0018:ffffb297079d7e08 EFLAGS: 00010206\nRAX: ffff8eb542c00040 RBX: ffff8eb541333150 RCX: 000000008010000d\nRDX: 000000008010000e RSI: 000000008010000d RDI: ffff8eb440042c00\nRBP: ffffb297079d7e48 R08: 0000000000000001 R09: ffffffff9fdeac00\nR10: ffff8eb5003be000 R11: 0000000000000001 R12: ffffffffa1545620\nR13: ffffffffa1545628 R14: 0000000000000000 R15: ffffffffa1543b20\nFS: 0000000000000000(0000) GS:ffff8ed37fa00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005601b5f4c2e8 CR3: 0000001fc8c10002 CR4: 00000000003706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ops_exit_list.isra.9+0x36/0x70\n cleanup_net+0x234/0x390\n process_one_work+0x1cb/0x360\n ? process_one_work+0x360/0x360\n worker_thread+0x30/0x370\n ? process_one_work+0x360/0x360\n kthread+0x116/0x130\n ? kthread_park+0x80/0x80\n ret_from_fork+0x22/0x30\n\nTo avoid the above warning and later on the kernel panic that could happen\non shutdown due to a NULL pointer dereference, make sure to set the\nnetns_refund flag that was introduced by commit 3a5ca857079e (\"can: dev:\nMove device back to init netns on owning netns delete\") to properly\nrestore the IPoIB interfaces to the initial netns."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/ipoib: Correcci\u00f3n de advertencia causada por la destrucci\u00f3n de redes no iniciales. Despu\u00e9s de la confirmaci\u00f3n 5ce2dced8e95 (\"RDMA/ipoib: Establecer rtnl_link_ops para interfaces ipoib\"), si el dispositivo IPoIB se mueve a redes no iniciales, destruir esas redes permite que el dispositivo desaparezca en lugar de moverlo nuevamente a las redes iniciales. Esto sucede porque default_device_exit() omite las interfaces debido a que tiene rtnl_link_ops configurado. Pasos para reproducir: ip netns agregar foo ip link set mlx5_ib0 netns foo ip netns eliminar foo ADVERTENCIA: CPU: 1 PID: 704 en net/core/dev.c:11435 netdev_exit+0x3f/0x50 M\u00f3dulos vinculados en: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ip v4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun d fuse CPU: 1 PID: 704 Comm: kworker/u64:3 Contaminado: GSW 5.13.0-rc1+ #1 Nombre de hardware: Dell Inc. PowerEdge R6 30/02C2CP, BIOS 2.1.5 11/04/2016 Cola de trabajo: netns cleanup_net RIP: 0010:netdev_exit+0x3f/0x50 C\u00f3digo: 48 8b bb 30 01 00 00 e8 ef 81 b1 ff 48 81 fb c0 3a 54 a1 74 13 48 8b 83 90 00 00 00 48 81 c3 90 00 00 00 48 39 d8 75 02 5b c3 <0f> 0b 5b c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00 RSP: 0018:ffffb297079d7e08 : 00010206 RAX: ffff8eb542c00040 RBX: ffff8eb541333150 RCX : 000000008010000d RDX: 000000008010000e RSI: 000000008010000d RDI: ffff8eb440042c00 RBP: ffffb297079d7e48 R08: 0000000000000001 R09: ff9fdeac00 R10: ffff8eb5003be000 R11: 0000000000000001 R12: ffffffffa1545620 R13: ffffffffa1545628 R14: 00000000000000000 R15: ffffffffa1543b20 FS: 0000000000(0000) GS:ffff8ed37fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005601b5f4c2e8 CR3: 0000001fc8c10002 CR4: 00000000003706e0 0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ops_exit _list.isra.9 +0x36/0x70 cleanup_net+0x234/0x390 Process_one_work+0x1cb/0x360 ? Process_one_work+0x360/0x360 worker_thread+0x30/0x370 ? Process_one_work+0x360/0x360 kthread+0x116/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 Para evitar la advertencia anterior y m\u00e1s adelante el p\u00e1nico del kernel que podr\u00eda ocurrir al cerrar debido a una desreferencia del puntero NULL, aseg\u00farese de configurar el indicador netns_refund que fue introducido por la confirmaci\u00f3n 3a5ca857079e (\"can: dev: Mueva el dispositivo nuevamente a init netns al poseer netns eliminar\") para restaurar correctamente las interfaces IPoIB a las netns iniciales."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: fix various gadget panics on 10gbps cabling\n\nusb_assign_descriptors() is called with 5 parameters,\nthe last 4 of which are the usb_descriptor_header for:\n full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),\n high-speed (USB2.0 - 480Mbps),\n super-speed (USB3.0 - 5Gbps),\n super-speed-plus (USB3.1 - 10Gbps).\n\nThe differences between full/high/super-speed descriptors are usually\nsubstantial (due to changes in the maximum usb block size from 64 to 512\nto 1024 bytes and other differences in the specs), while the difference\nbetween 5 and 10Gbps descriptors may be as little as nothing\n(in many cases the same tuning is simply good enough).\n\nHowever if a gadget driver calls usb_assign_descriptors() with\na NULL descriptor for super-speed-plus and is then used on a max 10gbps\nconfiguration, the kernel will crash with a null pointer dereference,\nwhen a 10gbps capable device port + cable + host port combination shows up.\n(This wouldn't happen if the gadget max-speed was set to 5gbps, but\nit of course defaults to the maximum, and there's no real reason to\nartificially limit it)\n\nThe fix is to simply use the 5gbps descriptor as the 10gbps descriptor,\nif a 10gbps descriptor wasn't provided.\n\nObviously this won't fix the problem if the 5gbps descriptor is also\nNULL, but such cases can't be so trivially solved (and any such gadgets\nare unlikely to be used with USB3 ports any way)."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: corrige varios fallos de dispositivos en cableado de 10 gbps usb_assign_descriptors() se llama con 5 par\u00e1metros, los \u00faltimos 4 de los cuales son usb_descriptor_header para: velocidad completa (USB1.1 - 12Mbps [ incluyendo USB1.0 de baja velocidad a 1,5 Mbps), alta velocidad (USB2.0 - 480 Mbps), s\u00faper velocidad (USB3.0 - 5 Gbps), s\u00faper velocidad plus (USB3.1 - 10 Gbps). Las diferencias entre los descriptores de velocidad completa/alta/supervelocidad suelen ser sustanciales (debido a cambios en el tama\u00f1o m\u00e1ximo del bloque USB de 64 a 512 a 1024 bytes y otras diferencias en las especificaciones), mientras que la diferencia entre los descriptores de 5 y 10 Gbps puede ser tan casi nada (en muchos casos, la misma afinaci\u00f3n es simplemente suficiente). Sin embargo, si un controlador de dispositivo llama a usb_assign_descriptors() con un descriptor NULL para super-speed-plus y luego se usa en una configuraci\u00f3n m\u00e1xima de 10 gbps, el kernel fallar\u00e1 con una desreferencia de puntero null, cuando un puerto de dispositivo con capacidad de 10 gbps + cable + puerto de host Aparece la combinaci\u00f3n. (Esto no suceder\u00eda si la velocidad m\u00e1xima del dispositivo estuviera configurada en 5 gbps, pero, por supuesto, est\u00e1 predeterminada al m\u00e1ximo y no hay ninguna raz\u00f3n real para limitarla artificialmente). La soluci\u00f3n es simplemente usar el descriptor de 5 gbps como el descriptor de 10 gbps, si no se proporcion\u00f3 un descriptor de 10 gbps. Obviamente, esto no solucionar\u00e1 el problema si el descriptor de 5 gbps tambi\u00e9n es NULL, pero estos casos no se pueden resolver de manera tan trivial (y es poco probable que dichos dispositivos se utilicen con puertos USB3 de alguna manera)."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: tcpm: cancel vdm and state machine hrtimer when unregister tcpm port\n\nA pending hrtimer may expire after the kthread_worker of tcpm port\nis destroyed, see below kernel dump when do module unload, fix it\nby cancel the 2 hrtimers.\n\n[ 111.517018] Unable to handle kernel paging request at virtual address ffff8000118cb880\n[ 111.518786] blk_update_request: I/O error, dev sda, sector 60061185 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0\n[ 111.526594] Mem abort info:\n[ 111.526597] ESR = 0x96000047\n[ 111.526600] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 111.526604] SET = 0, FnV = 0\n[ 111.526607] EA = 0, S1PTW = 0\n[ 111.526610] Data abort info:\n[ 111.526612] ISV = 0, ISS = 0x00000047\n[ 111.526615] CM = 0, WnR = 1\n[ 111.526619] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041d75000\n[ 111.526623] [ffff8000118cb880] pgd=10000001bffff003, p4d=10000001bffff003, pud=10000001bfffe003, pmd=10000001bfffa003, pte=0000000000000000\n[ 111.526642] Internal error: Oops: 96000047 [#1] PREEMPT SMP\n[ 111.526647] Modules linked in: dwc3_imx8mp dwc3 phy_fsl_imx8mq_usb [last unloaded: tcpci]\n[ 111.526663] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-00927-gebbe9dbd802c-dirty #36\n[ 111.526670] Hardware name: NXP i.MX8MPlus EVK board (DT)\n[ 111.526674] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO BTYPE=--)\n[ 111.526681] pc : queued_spin_lock_slowpath+0x1a0/0x390\n[ 111.526695] lr : _raw_spin_lock_irqsave+0x88/0xb4\n[ 111.526703] sp : ffff800010003e20\n[ 111.526706] x29: ffff800010003e20 x28: ffff00017f380180\n[ 111.537156] buffer_io_error: 6 callbacks suppressed\n[ 111.537162] Buffer I/O error on dev sda1, logical block 60040704, async page read\n[ 111.539932] x27: ffff00017f3801c0\n[ 111.539938] x26: ffff800010ba2490 x25: 0000000000000000 x24: 0000000000000001\n[ 111.543025] blk_update_request: I/O error, dev sda, sector 60061186 op 0x0:(READ) flags 0x0 phys_seg 7 prio class 0\n[ 111.548304]\n[ 111.548306] x23: 00000000000000c0 x22: ffff0000c2a9f184 x21: ffff00017f380180\n[ 111.551374] Buffer I/O error on dev sda1, logical block 60040705, async page read\n[ 111.554499]\n[ 111.554503] x20: ffff0000c5f14210 x19: 00000000000000c0 x18: 0000000000000000\n[ 111.557391] Buffer I/O error on dev sda1, logical block 60040706, async page read\n[ 111.561218]\n[ 111.561222] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[ 111.564205] Buffer I/O error on dev sda1, logical block 60040707, async page read\n[ 111.570887] x14: 00000000000000f5 x13: 0000000000000001 x12: 0000000000000040\n[ 111.570902] x11: ffff0000c05ac6d8\n[ 111.583420] Buffer I/O error on dev sda1, logical block 60040708, async page read\n[ 111.588978] x10: 0000000000000000 x9 : 0000000000040000\n[ 111.588988] x8 : 0000000000000000\n[ 111.597173] Buffer I/O error on dev sda1, logical block 60040709, async page read\n[ 111.605766] x7 : ffff00017f384880 x6 : ffff8000118cb880\n[ 111.605777] x5 : ffff00017f384880\n[ 111.611094] Buffer I/O error on dev sda1, logical block 60040710, async page read\n[ 111.617086] x4 : 0000000000000000 x3 : ffff0000c2a9f184\n[ 111.617096] x2 : ffff8000118cb880\n[ 111.622242] Buffer I/O error on dev sda1, logical block 60040711, async page read\n[ 111.626927] x1 : ffff8000118cb880 x0 : ffff00017f384888\n[ 111.626938] Call trace:\n[ 111.626942] queued_spin_lock_slowpath+0x1a0/0x390\n[ 111.795809] kthread_queue_work+0x30/0xc0\n[ 111.799828] state_machine_timer_handler+0x20/0x30\n[ 111.804624] __hrtimer_run_queues+0x140/0x1e0\n[ 111.808990] hrtimer_interrupt+0xec/0x2c0\n[ 111.813004] arch_timer_handler_phys+0x38/0x50\n[ 111.817456] handle_percpu_devid_irq+0x88/0x150\n[ 111.821991] __handle_domain_irq+0x80/0xe0\n[ 111.826093] gic_handle_irq+0xc0/0x140\n[ 111.829848] el1_irq+0xbc/0x154\n[ 111.832991] arch_cpu_idle+0x1c/0x2c\n[ 111.836572] default_idle_call+0x24/0x6c\n[ 111.840497] do_idle+0x238/0x2ac\n[ 1\n---truncated---"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: cancela vdm y state machine hrtimer cuando se cancela el registro del puerto tcpm. Un hrtimer pendiente puede caducar despu\u00e9s de que se destruya el kthread_worker del puerto tcpm; consulte el siguiente volcado del kernel cuando se descarga el m\u00f3dulo , solucionelo cancelando los 2 temporizadores. [ 111.517018] No se puede manejar la solicitud de paginaci\u00f3n del kernel en la direcci\u00f3n virtual ffff8000118cb880 [ 111.518786] blk_update_request: error de E/S, dev sda, sector 60061185 op 0x0:(LEER) indicadores 0x0 phys_seg 1 prio clase 0 [ 111.526594] Informaci\u00f3n de cancelaci\u00f3n de memoria: [111.526597 ] ESR = 0x96000047 [ 111.526600] EC = 0x25: DABT (EL actual), IL = 32 bits [ 111.526604] SET = 0, FnV = 0 [ 111.526607] EA = 0, S1PTW = 0 [ 111.526610] Informaci\u00f3n de cancelaci\u00f3n de datos: [ 111. 526612 ] ISV = 0, ISS = 0x00000047 [ 111.526615] CM = 0, WnR = 1 [ 111.526619] tabla de intercambio: p\u00e1ginas de 4k, VA de 48 bits, pgdp=0000000041d75000 [ 111.526623 [ffff8000118cb] 880] pgd=10000001bffff003, p4d=10000001bffff003, pud\u00edn =10000001bfffe003, pmd=10000001bfffa003, pte=0000000000000000 [111.526642] Error interno: Ups: 96000047 [#1] SMP PREEMPLEO [111.526647] M\u00f3dulos vinculados en: dwc3_imx8mp dwc3 phy_fsl_imx8mq_usb [\u00faltima descarga: tcpci] [111.526663] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-00927-gebbe9dbd802c-dirty #36 [111.526670] Nombre del hardware: placa NXP i.MX8MPlus EVK (DT) [111.526674] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO BTYPE=--) [ 111.526681] pc : queued_spin_lock_slowpath+0x1a0/0x390 [ 111.526695] lr : _raw_spin_lock_irqsave+0x88/0xb4 [ 111.526703] sp : ffff800010003e20 [ 111.526 706] x29: ffff800010003e20 x28: ffff00017f380180 [111.537156] buffer_io_error: 6 devoluciones de llamada suprimidas [111.537162 ] Error de E/S del b\u00fafer en dev sda1, bloque l\u00f3gico 60040704, lectura de p\u00e1gina as\u00edncrona [111.539932] x27: ffff00017f3801c0 [111.539938] x26: ffff800010ba2490 x25: 0000000000000000 x24: 00000000000001 [111.543025] blk_update_request: error de E/S, dev sda, sector 60061186 op 0x0:(LEER) banderas 0x0 phys_seg 7 prio clase 0 [ 111.548304] [ 111.548306] x23: 00000000000000c0 x22: ffff0000c2a9f184 x21: ffff00017f380180 [ 111.551 374] Error de E/S del b\u00fafer en dev sda1, bloque l\u00f3gico 60040705, lectura de p\u00e1gina as\u00edncrona [111.554499] [111.554503] x20: ffff0000c5f14210 x19: 00000000000000c0 x18: 0000000000000000 [111.557391] Error de E/S del b\u00fafer en dev sda1, bloque l\u00f3gico 60040706, lectura de p\u00e1gina as\u00edncrona [111. 561218] [ 111.561222] x17: 0000000000000000 x16: 0000000000000000 x15: 00000000000000000 [ 111.564205] B\u00fafer Error de E/S en dev sda1, bloque l\u00f3gico 60040707, lectura de p\u00e1gina as\u00edncrona [111.570887] x14: 00000000000000f5 x13: 00000000000000001 x12: 0000000000000040 [111.570902] x11: ff0000c05ac6d8 [111.583420] Error de E/S del b\u00fafer en dev sda1, bloque l\u00f3gico 60040708, as\u00edncrono lectura de p\u00e1gina [111.588978] x10: 0000000000000000 x9: 0000000000040000 [111.588988] x8: 0000000000000000 [111.597173] Error de E/S del b\u00fafer en dev sda1, bloque l\u00f3gico 6004 0709, lectura de p\u00e1gina as\u00edncrona [111.605766] x7: ffff00017f384880 x6: ffff8000118cb880 [111.605777] x5: ffff00017f384880 [111.611094] Error de E/S del b\u00fafer en dev sda1, bloque l\u00f3gico 60040710, lectura de p\u00e1gina as\u00edncrona [111.617086] x4: 0000000000000000 x3: ffff0000c2a9f184 [111.617096] 2: ffff8000118cb880 [111.622242] Error de E/S del b\u00fafer en dev sda1, bloque l\u00f3gico 60040711 , lectura de p\u00e1gina as\u00edncrona [111.626927] x1: ffff8000118cb880 x0: ffff00017f384888 [111.626938] Seguimiento de llamadas: [111.626942] queued_spin_lock_slowpath+0x1a0/0x390 [111.795809] _queue_work+0x30/0xc0 [ 111.799828] state_machine_timer_handler+0x20/0x30 [ 111.804624] __hrtimer_run_queues+0x140/ 0x1e0 [ 111.808990] hrtimer_interrupt+0xec/0x2c0 [ 111.813004] arch_timer_handler_phys+0x38/0x50 [ 111.817456] handle_percpu_devid_irq+0x88/0x150 [ 111.821991] main_irq+0x80/0xe0 [ 111.826093] gic_handle_irq+0x ---truncado---"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: ep0: fix NULL pointer exception\n\nThere is no validation of the index from dwc3_wIndex_to_dep() and we might\nbe referring a non-existing ep and trigger a NULL pointer exception. In\ncertain configurations we might use fewer eps and the index might wrongly\nindicate a larger ep index than existing.\n\nBy adding this validation from the patch we can actually report a wrong\nindex back to the caller.\n\nIn our usecase we are using a composite device on an older kernel, but\nupstream might use this fix also. Unfortunately, I cannot describe the\nhardware for others to reproduce the issue as it is a proprietary\nimplementation.\n\n[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4\n[ 82.966891] Mem abort info:\n[ 82.969663] ESR = 0x96000006\n[ 82.972703] Exception class = DABT (current EL), IL = 32 bits\n[ 82.978603] SET = 0, FnV = 0\n[ 82.981642] EA = 0, S1PTW = 0\n[ 82.984765] Data abort info:\n[ 82.987631] ISV = 0, ISS = 0x00000006\n[ 82.991449] CM = 0, WnR = 0\n[ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc\n[ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000\n[ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP\n[ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)\n[ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1\n[ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)\n[ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c\n[ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94\n\n...\n\n[ 83.141788] Call trace:\n[ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c\n[ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94\n[ 83.181546] ---[ end trace aac6b5267d84c32f ]---"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: ep0: corrige excepci\u00f3n de puntero NULL. No hay validaci\u00f3n del \u00edndice desde dwc3_wIndex_to_dep() y podr\u00edamos estar haciendo referencia a un ep inexistente y desencadenar una excepci\u00f3n de puntero NULL. En ciertas configuraciones, podr\u00edamos usar menos eps y el \u00edndice podr\u00eda indicar err\u00f3neamente un \u00edndice ep mayor que el existente. Al agregar esta validaci\u00f3n del parche, podemos informar un \u00edndice incorrecto a la persona que llama. En nuestro caso de uso, estamos usando un dispositivo compuesto en un kernel m\u00e1s antiguo, pero el nivel superior tambi\u00e9n podr\u00eda usar esta soluci\u00f3n. Desafortunadamente, no puedo describir el hardware para que otros reproduzcan el problema ya que es una implementaci\u00f3n propietaria. [82.958261] No se puede manejar la desreferencia del puntero NULL del kernel en la direcci\u00f3n virtual 00000000000000a4 [82.966891] Informaci\u00f3n de cancelaci\u00f3n de memoria: [82.969663] ESR = 0x96000006 [82.972703] Clase de excepci\u00f3n = DABT (EL actual), IL = 32 bits [ 82.9 78603] CONFIGURAR = 0, FnV = 0 [82.981642] EA = 0, S1PTW = 0 [82.984765] Informaci\u00f3n de cancelaci\u00f3n de datos: [82.987631] ISV = 0, ISS = 0x00000006 [82.991449] CM = 0, WnR = 0 [82.994409] tabla de usuario 4k: p\u00e1ginas, 39 VA de bits, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.00 9685] Error interno: Oops: 96000006 [#1] SMP PREEMPTO [83.026433] Proceso irq/62-dwc3 (pid : 303, l\u00edmite de pila = 0x000000003985154c) [83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 No contaminado 4.19.124 #1 [83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 49628] ordenador personal: dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94 ... [ 83.141788] Rastreo de llamadas: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148 823] dwc3_ep0_interrupt+0x3b4/0xc94 [83.181546] ---[ final de seguimiento aac6b5267d84c32f ]---"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: fix various gadgets null ptr deref on 10gbps cabling.\n\nThis avoids a null pointer dereference in\nf_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}\nby simply reusing the 5gbps config for 10gbps."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: repara varios gadgets null ptr deref en cableado de 10gbps. Esto evita una desreferencia de puntero null en f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} simplemente reutilizando la configuraci\u00f3n de 5 gbps para 10 gbps."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler\n\nPatch fixes the following critical issue caused by deadlock which has been\ndetected during testing NCM class:\n\nsmp: csd: Detected non-responsive CSD lock (#1) on CPU#0\nsmp: csd: CSD lock (#1) unresponsive.\n....\nRIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0\nRSP: 0018:ffffbc494011cde0 EFLAGS: 00000002\nRAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658\nRBP: ffffbc494011cde0 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658\nR13: ffff9ee8116b4670 R14: 0000000000000246 R15: ffff9ee8116b4658\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0\nCall Trace:\n <IRQ>\n do_raw_spin_lock+0xc0/0xd0\n _raw_spin_lock_irqsave+0x95/0xa0\n cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci]\n usb_ep_queue+0x35/0x110\n eth_start_xmit+0x220/0x3d0 [u_ether]\n ncm_tx_timeout+0x34/0x40 [usb_f_ncm]\n ? ncm_free_inst+0x50/0x50 [usb_f_ncm]\n __hrtimer_run_queues+0xac/0x440\n hrtimer_run_softirq+0x8c/0xb0\n __do_softirq+0xcf/0x428\n asm_call_irq_on_stack+0x12/0x20\n </IRQ>\n do_softirq_own_stack+0x61/0x70\n irq_exit_rcu+0xc1/0xd0\n sysvec_apic_timer_interrupt+0x52/0xb0\n asm_sysvec_apic_timer_interrupt+0x12/0x20\nRIP: 0010:do_raw_spin_trylock+0x18/0x40\nRSP: 0018:ffffbc494138bda8 EFLAGS: 00000246\nRAX: 0000000000000000 RBX: ffff9ee8116b4658 RCX: 0000000000000000\nRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9ee8116b4658\nRBP: ffffbc494138bda8 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658\nR13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000\n _raw_spin_lock+0x3d/0x70\n ? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]\n cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]\n ? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci]\n ? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci]\n ? irq_thread+0xa0/0x1c0\n irq_thread_fn+0x28/0x60\n irq_thread+0x105/0x1c0\n ? __kthread_parkme+0x42/0x90\n ? irq_forced_thread_fn+0x90/0x90\n ? wake_threads_waitq+0x30/0x30\n ? irq_thread_check_affinity+0xe0/0xe0\n kthread+0x12a/0x160\n ? kthread_park+0x90/0x90\n ret_from_fork+0x22/0x30\n\nThe root cause of issue is spin_lock/spin_unlock instruction instead\nspin_lock_irqsave/spin_lock_irqrestore in cdnsp_thread_irq_handler\nfunction."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdnsp: soluciona el problema de interbloqueo en cdnsp_thread_irq_handler. El parche corrige el siguiente problema cr\u00edtico causado por el interbloqueo que se detect\u00f3 durante las pruebas Clase NCM: smp: csd: se detect\u00f3 un bloqueo CSD que no responde ( #1) en CPU#0 smp: csd: el bloqueo CSD (#1) no responde. .... RIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0 RSP: 0018:ffffbc494011cde0 EFLAGS: 00000002 RAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658 RBP: ffffbc494011cde0 R08: 0000000000000001 R09: 00000000000000000 R 10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658 R13: ffff9ee8116b4670 R14: 00000000000000246 R15: ffff9ee8116b4658 CS: 0010 DS: 0 ES: 0000 CR0: 0000000080050033 CR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0 Seguimiento de llamadas: do_raw_spin_lock+0xc0/0xd0 _raw_spin_lock_irqsave + 0x95/0xa0 cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci] usb_ep_queue+0x35/0x110 eth_start_xmit+0x220/0x3d0 [u_ether] ncm_tx_timeout+0x34/0x40 [usb_f_ncm] ? ncm_free_inst+0x50/0x50 [usb_f_ncm] __hrtimer_run_queues+0xac/0x440 hrtimer_run_softirq+0x8c/0xb0 __do_softirq+0xcf/0x428 asm_call_irq_on_stack+0x12/0x20 +0x61/0x70 irq_exit_rcu+0xc1/0xd0 sysvec_apic_timer_interrupt+0x52/0xb0 asm_sysvec_apic_timer_interrupt+0x12 /0x20 RIP: 0010:do_raw_spin_trylock+0x18/0x40 RSP: 0018:ffffbc494138bda8 EFLAGS: 00000246 RAX: 00000000000000000 RBX: ffff9ee8116b4658 RCX: 0000000000000 000 RDX: 0000000000000001 RSI: 00000000000000000 RDI: ffff9ee8116b4658 RBP: ffffbc494138bda8 R08: 00000000000000001 R09: 0000000000000000 R10: ffff9ee8116b4670 R11 : 0000000000000000 R12: ffff9ee8116b4658 R13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000 _raw_spin_lock+0x3d/0x70 ? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci] cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci] ? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci] ? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci] ? irq_thread+0xa0/0x1c0 irq_thread_fn+0x28/0x60 irq_thread+0x105/0x1c0 ? __kthread_parkme+0x42/0x90 ? irq_forced_thread_fn+0x90/0x90? wake_threads_waitq+0x30/0x30? irq_thread_check_affinity+0xe0/0xe0 kthread+0x12a/0x160 ? kthread_park+0x90/0x90 ret_from_fork+0x22/0x30 La causa principal del problema es la instrucci\u00f3n spin_lock/spin_unlock en lugar de spin_lock_irqsave/spin_lock_irqrestore en la funci\u00f3n cdnsp_thread_irq_handler."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL\n\nThere exists a possible scenario in which dwc3_gadget_init() can fail:\nduring during host -> peripheral mode switch in dwc3_set_mode(), and\na pending gadget driver fails to bind. Then, if the DRD undergoes\nanother mode switch from peripheral->host the resulting\ndwc3_gadget_exit() will attempt to reference an invalid and dangling\ndwc->gadget pointer as well as call dma_free_coherent() on unmapped\nDMA pointers.\n\nThe exact scenario can be reproduced as follows:\n - Start DWC3 in peripheral mode\n - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs)\n - Run FunctionFS userspace application (open EPs, write descriptors, etc)\n - Bind gadget driver to DWC3's UDC\n - Switch DWC3 to host mode\n => dwc3_gadget_exit() is called. usb_del_gadget() will put the\n\tConfigFS driver instance on the gadget_driver_pending_list\n - Stop FunctionFS application (closes the ep files)\n - Switch DWC3 to peripheral mode\n => dwc3_gadget_init() fails as usb_add_gadget() calls\n\tcheck_pending_gadget_drivers() and attempts to rebind the UDC\n\tto the ConfigFS gadget but fails with -19 (-ENODEV) because the\n\tFFS instance is not in FFS_ACTIVE state (userspace has not\n\tre-opened and written the descriptors yet, i.e. desc_ready!=0).\n - Switch DWC3 back to host mode\n => dwc3_gadget_exit() is called again, but this time dwc->gadget\n\tis invalid.\n\nAlthough it can be argued that userspace should take responsibility\nfor ensuring that the FunctionFS application be ready prior to\nallowing the composite driver bind to the UDC, failure to do so\nshould not result in a panic from the kernel driver.\n\nFix this by setting dwc->gadget to NULL in the failure path of\ndwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out\nunless the gadget pointer is valid."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: Bail from dwc3_gadget_exit() si dwc->gadget es NULL. Existe un posible escenario en el que dwc3_gadget_init() puede fallar: durante durante el host -> modo perif\u00e9rico Cambie a dwc3_set_mode() y un controlador de dispositivo pendiente no se vincula. Luego, si el DRD sufre otro cambio de modo desde perif\u00e9rico->host, el dwc3_gadget_exit() resultante intentar\u00e1 hacer referencia a un puntero dwc->gadget no v\u00e1lido y colgante, as\u00ed como llamar a dma_free_coherent() en punteros DMA no asignados. El escenario exacto se puede reproducir de la siguiente manera: - Iniciar DWC3 en modo perif\u00e9rico - Configurar el gadget ConfigFS con la instancia FunctionFS (o usar g_ffs) - Ejecutar la aplicaci\u00f3n de espacio de usuario FunctionFS (abrir EP, escribir descriptores, etc.) - Vincular el controlador del gadget al UDC de DWC3 - Cambiar DWC3 al modo host => se llama a dwc3_gadget_exit(). usb_del_gadget() colocar\u00e1 la instancia del controlador ConfigFS en gadget_driver_pending_list - Detener la aplicaci\u00f3n FunctionFS (cierra los archivos ep) - Cambiar DWC3 al modo perif\u00e9rico => dwc3_gadget_init() falla ya que usb_add_gadget() llama a check_pending_gadget_drivers() e intenta volver a vincular el UDC al El gadget ConfigFS pero falla con -19 (-ENODEV) porque la instancia FFS no est\u00e1 en estado FFS_ACTIVE (el espacio de usuario a\u00fan no se ha reabierto ni escrito los descriptores, es decir, desc_ready!=0). - Vuelva a cambiar DWC3 al modo host => se vuelve a llamar a dwc3_gadget_exit(), pero esta vez dwc->gadget no es v\u00e1lido. Aunque se puede argumentar que el espacio de usuario debe asumir la responsabilidad de garantizar que la aplicaci\u00f3n FunctionFS est\u00e9 lista antes de permitir que el controlador compuesto se vincule al UDC, no hacerlo no deber\u00eda generar p\u00e1nico por parte del controlador del kernel. Solucione este problema configurando dwc->gadget en NULL en la ruta de falla de dwc3_gadget_init() y agregue una marca a dwc3_gadget_exit() para salir del problema a menos que el puntero del gadget sea v\u00e1lido."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled\n\nWhen only PHY1 is used (for example on Odroid-HC4), the regmap init code\nuses the usb2 ports when doesn't initialize the PHY1 regmap entry.\n\nThis fixes:\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000020\n...\npc : regmap_update_bits_base+0x40/0xa0\nlr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8\n...\nCall trace:\nregmap_update_bits_base+0x40/0xa0\ndwc3_meson_g12a_usb2_init_phy+0x4c/0xf8\ndwc3_meson_g12a_usb2_init+0x7c/0xc8\ndwc3_meson_g12a_usb_init+0x28/0x48\ndwc3_meson_g12a_probe+0x298/0x540\nplatform_probe+0x70/0xe0\nreally_probe+0xf0/0x4d8\ndriver_probe_device+0xfc/0x168\n..."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3-meson-g12a: repara el init de glue PHY de usb2 cuando phy0 est\u00e1 deshabilitado. Cuando solo se usa PHY1 (por ejemplo, en Odroid-HC4), el c\u00f3digo de inicio de regmap usa usb2 puertos cuando no inicializa la entrada del mapa de registro PHY1. Esto soluciona: No se puede manejar la desreferencia del puntero NULL del kernel en la direcci\u00f3n virtual 0000000000000020... pc: regmap_update_bits_base+0x40/0xa0 lr: dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8... Seguimiento de llamadas: regmap_update_bits_base+0x40/0xa0 g12a_usb2_init_phy+0x4c/0xf8 dwc3_meson_g12a_usb2_init+0x7c /0xc8 dwc3_meson_g12a_usb_init+0x28/0x48 dwc3_meson_g12a_probe+0x298/0x540 platform_probe+0x70/0xe0 Actually_probe+0xf0/0x4d8 driver_probe_device+0xfc/0x168 ..."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Correct the length check which causes memory corruption\n\nWe've suffered from severe kernel crashes due to memory corruption on\nour production environment, like,\n\nCall Trace:\n[1640542.554277] general protection fault: 0000 [#1] SMP PTI\n[1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G\n[1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190\n[1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286\n[1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:\n0000000006e931bf\n[1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:\nffff9a45ff004300\n[1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:\n0000000000000000\n[1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:\nffffffff9a20608d\n[1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:\n696c662f65636976\n[1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)\nknlGS:0000000000000000\n[1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:\n00000000003606e0\n[1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[1640542.566742] Call Trace:\n[1640542.567009] anon_vma_clone+0x5d/0x170\n[1640542.567417] __split_vma+0x91/0x1a0\n[1640542.567777] do_munmap+0x2c6/0x320\n[1640542.568128] vm_munmap+0x54/0x70\n[1640542.569990] __x64_sys_munmap+0x22/0x30\n[1640542.572005] do_syscall_64+0x5b/0x1b0\n[1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9\n[1640542.575642] RIP: 0033:0x7f45d6e61e27\n\nJames Wang has reproduced it stably on the latest 4.19 LTS.\nAfter some debugging, we finally proved that it's due to ftrace\nbuffer out-of-bound access using a debug tool as follows:\n[ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000\n[ 86.780806] no_context+0xdf/0x3c0\n[ 86.784327] __do_page_fault+0x252/0x470\n[ 86.788367] do_page_fault+0x32/0x140\n[ 86.792145] page_fault+0x1e/0x30\n[ 86.795576] strncpy_from_unsafe+0x66/0xb0\n[ 86.799789] fetch_memory_string+0x25/0x40\n[ 86.804002] fetch_deref_string+0x51/0x60\n[ 86.808134] kprobe_trace_func+0x32d/0x3a0\n[ 86.812347] kprobe_dispatcher+0x45/0x50\n[ 86.816385] kprobe_ftrace_handler+0x90/0xf0\n[ 86.820779] ftrace_ops_assist_func+0xa1/0x140\n[ 86.825340] 0xffffffffc00750bf\n[ 86.828603] do_sys_open+0x5/0x1f0\n[ 86.832124] do_syscall_64+0x5b/0x1b0\n[ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\ncommit b220c049d519 (\"tracing: Check length before giving out\nthe filter buffer\") adds length check to protect trace data\noverflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent\noverflow entirely, the length check should also take the sizeof\nentry->array[0] into account, since this array[0] is filled the\nlength of trace data and occupy addtional space and risk overflow."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: rastreo: corrija la verificaci\u00f3n de longitud que causa corrupci\u00f3n de la memoria. Hemos sufrido fallos graves del kernel debido a la corrupci\u00f3n de la memoria en nuestro entorno de producci\u00f3n, como Call Trace: [1640542.554277] fallo de protecci\u00f3n general. : 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: cargado Contaminado:G [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] : 0018:ffffb16faa597df8 EFLAGS: 00010286 [ 1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX: 0000000006e931be RSI: 0000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09: 0000000000000000 [1640542.561670] : 0000000000000000 R11: 0000000000000000 R12: ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) GS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.5 66069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Seguimiento de llamadas: [1640542.567009] anon_vma_clone+0x5d/0x170 2.567417] __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] _64+0x5b/0x1b0 [1640542.573724] entrada_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang lo ha reproducido de forma estable en la \u00faltima versi\u00f3n 4.19 LTS. Despu\u00e9s de algunas depuraciones, finalmente demostramos que se debe al acceso fuera de los l\u00edmites al b\u00fafer ftrace usando una herramienta de depuraci\u00f3n de la siguiente manera: [86.775200] ERROR: Escritura fuera de los l\u00edmites en la direcci\u00f3n 0xffff88aefe8b7000 [86.780806] no_context+0xdf/0x3c0 [86.784327 ] __do_page_fault+0x252/0x470 [ 86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] ry_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func +0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] ffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [ 86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900 ] Entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 (\"rastreo: verificar la longitud antes de entregar el b\u00fafer de filtro\") agrega verificaci\u00f3n de longitud para proteger el desbordamiento de datos de seguimiento introducido en 0fc1b09ff1ff, parece que esta soluci\u00f3n no puede evitar el desbordamiento por completo, la verificaci\u00f3n de longitud tambi\u00e9n deber\u00eda tenga en cuenta el tama\u00f1o de la entrada->matriz[0], ya que esta matriz[0] ocupa toda la longitud de los datos de seguimiento y ocupa espacio adicional y corre el riesgo de desbordarse."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbcache: avoid oversized read request in cache missing code path\n\nIn the cache missing code path of cached device, if a proper location\nfrom the internal B+ tree is matched for a cache miss range, function\ncached_dev_cache_miss() will be called in cache_lookup_fn() in the\nfollowing code block,\n[code block 1]\n 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode\n 527 ? min_t(uint64_t, INT_MAX,\n 528 KEY_START(k) - bio->bi_iter.bi_sector)\n 529 : INT_MAX;\n 530 int ret = s->d->cache_miss(b, s, bio, sectors);\n\nHere s->d->cache_miss() is the call backfunction pointer initialized as\ncached_dev_cache_miss(), the last parameter 'sectors' is an important\nhint to calculate the size of read request to backing device of the\nmissing cache data.\n\nCurrent calculation in above code block may generate oversized value of\n'sectors', which consequently may trigger 2 different potential kernel\npanics by BUG() or BUG_ON() as listed below,\n\n1) BUG_ON() inside bch_btree_insert_key(),\n[code block 2]\n 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k));\n2) BUG() inside biovec_slab(),\n[code block 3]\n 51 default:\n 52 BUG();\n 53 return NULL;\n\nAll the above panics are original from cached_dev_cache_miss() by the\noversized parameter 'sectors'.\n\nInside cached_dev_cache_miss(), parameter 'sectors' is used to calculate\nthe size of data read from backing device for the cache missing. This\nsize is stored in s->insert_bio_sectors by the following lines of code,\n[code block 4]\n 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada);\n\nThen the actual key inserting to the internal B+ tree is generated and\nstored in s->iop.replace_key by the following lines of code,\n[code block 5]\n 911 s->iop.replace_key = KEY(s->iop.inode,\n 912 bio->bi_iter.bi_sector + s->insert_bio_sectors,\n 913 s->insert_bio_sectors);\nThe oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from\nthe above code block.\n\nAnd the bio sending to backing device for the missing data is allocated\nwith hint from s->insert_bio_sectors by the following lines of code,\n[code block 6]\n 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT,\n 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS),\n 928 &dc->disk.bio_split);\nThe oversized parameter 'sectors' may trigger panic 2) by BUG() from the\nagove code block.\n\nNow let me explain how the panics happen with the oversized 'sectors'.\nIn code block 5, replace_key is generated by macro KEY(). From the\ndefinition of macro KEY(),\n[code block 7]\n 71 #define KEY(inode, offset, size) \\\n 72 ((struct bkey) { \\\n 73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \\\n 74 .low = (offset) \\\n 75 })\n\nHere 'size' is 16bits width embedded in 64bits member 'high' of struct\nbkey. But in code block 1, if \"KEY_START(k) - bio->bi_iter.bi_sector\" is\nvery probably to be larger than (1<<16) - 1, which makes the bkey size\ncalculation in code block 5 is overflowed. In one bug report the value\nof parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors'\nresults the overflowed s->insert_bio_sectors in code block 4, then makes\nsize field of s->iop.replace_key to be 0 in code block 5. Then the 0-\nsized s->iop.replace_key is inserted into the internal B+ tree as cache\nmissing check key (a special key to detect and avoid a racing between\nnormal write request and cache missing read request) as,\n[code block 8]\n 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key);\n\nThen the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey\nsize check BUG_ON() in code block 2, and causes the kernel panic 1).\n\nAnother ke\n---truncated---"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: evita solicitudes de lectura de gran tama\u00f1o en la ruta del c\u00f3digo faltante de la cach\u00e9. En la ruta del c\u00f3digo faltante de la cach\u00e9 del dispositivo almacenado en cach\u00e9, si una ubicaci\u00f3n adecuada del \u00e1rbol B+ interno coincide con un rango de falta de cach\u00e9, La funci\u00f3n cached_dev_cache_miss() se llamar\u00e1 en cache_lookup_fn() en el siguiente bloque de c\u00f3digo, [bloque de c\u00f3digo 1] 526 unsigned int sectores = KEY_INODE(k) == s->iop.inode 527? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529: INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors); Aqu\u00ed s->d->cache_miss() es el puntero de funci\u00f3n de devoluci\u00f3n de llamada inicializado como cached_dev_cache_miss(), el \u00faltimo par\u00e1metro 'sectors' es una pista importante para calcular el tama\u00f1o de la solicitud de lectura al dispositivo de respaldo de los datos de cach\u00e9 faltantes. El c\u00e1lculo actual en el bloque de c\u00f3digo anterior puede generar un valor sobredimensionado de 'sectors', lo que en consecuencia puede desencadenar 2 posibles p\u00e1nicos del kernel diferentes mediante BUG() o BUG_ON() como se enumera a continuaci\u00f3n, 1) BUG_ON() dentro de bch_btree_insert_key(), [bloque de c\u00f3digo 2 ] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() dentro de biovec_slab(), [bloque de c\u00f3digo 3] 51 predeterminado: 52 BUG(); 53 devuelve NULO; Todos los p\u00e1nicos anteriores son originales de cached_dev_cache_miss() por el par\u00e1metro 'sectors' de gran tama\u00f1o. Dentro de cached_dev_cache_miss(), el par\u00e1metro 'sectors' se utiliza para calcular el tama\u00f1o de los datos le\u00eddos desde el dispositivo de respaldo para el cach\u00e9 que falta. Este tama\u00f1o se almacena en s->insert_bio_sectors mediante las siguientes l\u00edneas de c\u00f3digo, [bloque de c\u00f3digo 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Luego, la clave real que se inserta en el \u00e1rbol B+ interno se genera y almacena en s->iop.replace_key mediante las siguientes l\u00edneas de c\u00f3digo, [bloque de c\u00f3digo 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insertar_bio_sectores, 913 s->insertar_bio_sectores); El par\u00e1metro 'sectors' de gran tama\u00f1o puede provocar p\u00e1nico 1) mediante BUG_ON() del bloque de c\u00f3digo anterior. Y el env\u00edo de biograf\u00eda al dispositivo de respaldo para los datos faltantes se asigna con una sugerencia de s->insert_bio_sectors mediante las siguientes l\u00edneas de c\u00f3digo, [bloque de c\u00f3digo 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); Los 'sectors' de par\u00e1metros de gran tama\u00f1o pueden provocar p\u00e1nico 2) mediante BUG() desde el bloque de c\u00f3digo anterior. Ahora perm\u00edtanme explicar c\u00f3mo se produce el p\u00e1nico en los \"sectors\" sobredimensionados. En el bloque de c\u00f3digo 5, replace_key se genera mediante la macro KEY(). De la definici\u00f3n de macro KEY(), [bloque de c\u00f3digo 7] 71 #define KEY(inode, offset, size) \\ 72 ((struct bkey) { \\ 73 .high = (1ULL << 63) | ((__u64) ( tama\u00f1o) << 20) | (inodo), \\ 74 .low = (desplazamiento) \\ 75 }) Aqu\u00ed 'tama\u00f1o' es un ancho de 16 bits incrustado en el miembro 'alto' de 64 bits de la estructura bkey. Pero en el bloque de c\u00f3digo 1, si \"KEY_START(k) - bio->bi_iter.bi_sector\" es muy probable que sea mayor que (1<<16) - 1, lo que hace que el c\u00e1lculo del tama\u00f1o de la clave b en el bloque de c\u00f3digo 5 se desborde. En un informe de error, el valor del par\u00e1metro 'sectors' es 131072 (= 1 << 17), los 'sectors' desbordados dan como resultado s->insert_bio_sectors desbordados en el bloque de c\u00f3digo 4, luego convierte el campo de tama\u00f1o de s->iop.replace_key en sea 0 en el bloque de c\u00f3digo 5. Luego, el tama\u00f1o 0 s->iop.replace_key se inserta en el \u00e1rbol B+ interno como clave de verificaci\u00f3n de falta de cach\u00e9 (una clave especial para detectar y evitar una ejecuci\u00f3n entre la solicitud de escritura normal y la solicitud de lectura faltante de cach\u00e9) como, [bloque de c\u00f3digo 8] 915 ret = ---truncado---"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Do not blindly read the ip address in ftrace_bug()\n\nIt was reported that a bug on arm64 caused a bad ip address to be used for\nupdating into a nop in ftrace_init(), but the error path (rightfully)\nreturned -EINVAL and not -EFAULT, as the bug caused more than one error to\noccur. But because -EINVAL was returned, the ftrace_bug() tried to report\nwhat was at the location of the ip address, and read it directly. This\ncaused the machine to panic, as the ip was not pointing to a valid memory\naddress.\n\nInstead, read the ip address with copy_from_kernel_nofault() to safely\naccess the memory, and if it faults, report that the address faulted,\notherwise report what was in that location."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: ftrace: no lea ciegamente la direcci\u00f3n IP en ftrace_bug(). Se inform\u00f3 que un error en arm64 provoc\u00f3 que se usara una direcci\u00f3n IP incorrecta para actualizar a un nop en ftrace_init() , pero la ruta de error (con raz\u00f3n) devolvi\u00f3 -EINVAL y no -EFAULT, ya que el error provoc\u00f3 que ocurriera m\u00e1s de un error. Pero debido a que se devolvi\u00f3 -EINVAL, ftrace_bug() intent\u00f3 informar qu\u00e9 hab\u00eda en la ubicaci\u00f3n de la direcci\u00f3n IP y leerlo directamente. Esto provoc\u00f3 que la m\u00e1quina entrara en p\u00e1nico, ya que la IP no apuntaba a una direcci\u00f3n de memoria v\u00e1lida. En su lugar, lea la direcci\u00f3n IP con copy_from_kernel_nofault() para acceder de forma segura a la memoria y, si falla, informe que la direcci\u00f3n fall\u00f3; de lo contrario, informe qu\u00e9 hab\u00eda en esa ubicaci\u00f3n."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nkvm: avoid speculation-based attacks from out-of-range memslot accesses\n\nKVM's mechanism for accessing guest memory translates a guest physical\naddress (gpa) to a host virtual address using the right-shifted gpa\n(also known as gfn) and a struct kvm_memory_slot. The translation is\nperformed in __gfn_to_hva_memslot using the following formula:\n\n hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE\n\nIt is expected that gfn falls within the boundaries of the guest's\nphysical memory. However, a guest can access invalid physical addresses\nin such a way that the gfn is invalid.\n\n__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first\nretrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot\ndoes check that the gfn falls within the boundaries of the guest's\nphysical memory or not, a CPU can speculate the result of the check and\ncontinue execution speculatively using an illegal gfn. The speculation\ncan result in calculating an out-of-bounds hva. If the resulting host\nvirtual address is used to load another guest physical address, this\nis effectively a Spectre gadget consisting of two consecutive reads,\nthe second of which is data dependent on the first.\n\nRight now it's not clear if there are any cases in which this is\nexploitable. One interesting case was reported by the original author\nof this patch, and involves visiting guest page tables on x86. Right\nnow these are not vulnerable because the hva read goes through get_user(),\nwhich contains an LFENCE speculation barrier. However, there are\npatches in progress for x86 uaccess.h to mask kernel addresses instead of\nusing LFENCE; once these land, a guest could use speculation to read\nfrom the VMM's ring 3 address space. Other architectures such as ARM\nalready use the address masking method, and would be susceptible to\nthis same kind of data-dependent access gadgets. Therefore, this patch\nproactively protects from these attacks by masking out-of-bounds gfns\nin __gfn_to_hva_memslot, which blocks speculation of invalid hvas.\n\nSean Christopherson noted that this patch does not cover\nkvm_read_guest_offset_cached. This however is limited to a few bytes\npast the end of the cache, and therefore it is unlikely to be useful in\nthe context of building a chain of data dependent accesses."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kvm: evite ataques basados en especulacion desde accesos a memslot fuera de rango. El mecanismo de KVM para acceder a la memoria del invitado traduce una direcci\u00f3n f\u00edsica del invitado (gpa) a una direcci\u00f3n virtual del host usando el bot\u00f3n derecho. gpa desplazado (tambi\u00e9n conocido como gfn) y una estructura kvm_memory_slot. La traducci\u00f3n se realiza en __gfn_to_hva_memslot usando la siguiente f\u00f3rmula: hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE Se espera que gfn est\u00e9 dentro de los l\u00edmites de la memoria f\u00edsica del hu\u00e9sped. Sin embargo, un invitado puede acceder a direcciones f\u00edsicas no v\u00e1lidas de tal manera que el gfn no sea v\u00e1lido. __gfn_to_hva_memslot se llama desde kvm_vcpu_gfn_to_hva_prot, que primero recupera un memslot a trav\u00e9s de __gfn_to_memslot. Si bien __gfn_to_memslot verifica que el gfn est\u00e9 dentro de los l\u00edmites de la memoria f\u00edsica del hu\u00e9sped o no, una CPU puede especular el resultado de la verificaci\u00f3n y continuar la ejecuci\u00f3n de manera especulativa usando un gfn ilegal. La especulaci\u00f3n puede resultar en el c\u00e1lculo de un hva fuera de los l\u00edmites. Si la direcci\u00f3n virtual del host resultante se utiliza para cargar otra direcci\u00f3n f\u00edsica de invitado, se trata efectivamente de un dispositivo Spectre que consta de dos lecturas consecutivas, la segunda de las cuales depende de los datos de la primera. En este momento no est\u00e1 claro si hay casos en los que esto sea explotable. El autor original de este parche inform\u00f3 un caso interesante que implica visitar tablas de p\u00e1ginas de invitados en x86. En este momento, estos no son vulnerables porque la lectura de hva pasa por get_user(), que contiene una barrera de especulaci\u00f3n LFENCE. Sin embargo, hay parches en progreso para x86 uaccess.h para enmascarar las direcciones del kernel en lugar de usar LFENCE; Una vez que aterrizan, un invitado podr\u00eda usar la especulaci\u00f3n para leer desde el espacio de direcciones del anillo 3 del VMM. Otras arquitecturas, como ARM, ya utilizan el m\u00e9todo de enmascaramiento de direcciones y ser\u00edan susceptibles a este mismo tipo de dispositivos de acceso dependientes de datos. Por lo tanto, este parche protege proactivamente contra estos ataques al enmascarar gfns fuera de los l\u00edmites en __gfn_to_hva_memslot, lo que bloquea la especulaci\u00f3n sobre hvas no v\u00e1lidos. Sean Christopherson se\u00f1al\u00f3 que este parche no cubre kvm_read_guest_offset_cached. Sin embargo, esto se limita a unos pocos bytes despu\u00e9s del final de la cach\u00e9 y, por lo tanto, es poco probable que sea \u00fatil en el contexto de la construcci\u00f3n de una cadena de accesos dependientes de datos."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: pci_generic: Fix possible use-after-free in mhi_pci_remove()\n\nThis driver's remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver's remove function\nhas finished, which would result in a use-after-free.\n\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: pci_generic: corrige posible use after free en mhi_pci_remove(). La ruta de eliminaci\u00f3n de este controlador llama a del_timer(). Sin embargo, esa funci\u00f3n no espera hasta que finalice el controlador del temporizador. Esto significa que es posible que el controlador del temporizador a\u00fan est\u00e9 ejecut\u00e1ndose despu\u00e9s de que haya finalizado la funci\u00f3n de eliminaci\u00f3n del controlador, lo que dar\u00eda como resultado un use after free. Para solucionarlo, llame a del_timer_sync(), lo que garantiza que el controlador del temporizador haya finalizado y no pueda reprogramarse."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource()\n\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: misc: brcmstb-usb-pinmap: verifique el valor de retorno despu\u00e9s de llamar a platform_get_resource() Causar\u00e1 un null-ptr-deref si platform_get_resource() devuelve NULL, necesitamos verificar el retorno valor."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: Fix use-after-free read in drm_getunique()\n\nThere is a time-of-check-to-time-of-use error in drm_getunique() due\nto retrieving file_priv->master prior to locking the device's master\nmutex.\n\nAn example can be seen in the crash report of the use-after-free error\nfound by Syzbot:\nhttps://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803\n\nIn the report, the master pointer was used after being freed. This is\nbecause another process had acquired the device's master mutex in\ndrm_setmaster_ioctl(), then overwrote fpriv->master in\ndrm_new_set_master(). The old value of fpriv->master was subsequently\nfreed before the mutex was unlocked.\n\nTo fix this, we lock the device's master mutex before retrieving the\npointer from from fpriv->master. This patch passes the Syzbot\nreproducer test."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: corrige la lectura de use after free en drm_getunique(). Hay un error de tiempo de verificaci\u00f3n a tiempo de uso en drm_getunique() debido a la recuperaci\u00f3n de file_priv. ->master antes de bloquear el mutex maestro del dispositivo. Se puede ver un ejemplo en el informe de fallo del error de use after free encontrado por Syzbot: https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 En el informe, el puntero maestro se utiliz\u00f3 despu\u00e9s de ser liberado. Esto se debe a que otro proceso adquiri\u00f3 el mutex maestro del dispositivo en drm_setmaster_ioctl() y luego sobrescribi\u00f3 fpriv->master en drm_new_set_master(). El antiguo valor de fpriv->master se liber\u00f3 posteriormente antes de que se desbloqueara el mutex. Para solucionar este problema, bloqueamos el mutex maestro del dispositivo antes de recuperar el puntero desde fpriv->master. Este parche pasa la prueba del reproductor Syzbot."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: seq: Fix race of snd_seq_timer_open()\n\nThe timer instance per queue is exclusive, and snd_seq_timer_open()\nshould have managed the concurrent accesses. It looks as if it's\nchecking the already existing timer instance at the beginning, but\nit's not right, because there is no protection, hence any later\nconcurrent call of snd_seq_timer_open() may override the timer\ninstance easily. This may result in UAF, as the leftover timer\ninstance can keep running while the queue itself gets closed, as\nspotted by syzkaller recently.\n\nFor avoiding the race, add a proper check at the assignment of\ntmr->timeri again, and return -EBUSY if it's been already registered."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ALSA: seq: Fix race of snd_seq_timer_open(). La instancia del temporizador por cola es exclusiva, y snd_seq_timer_open() deber\u00eda haber gestionado los accesos concurrentes. Parece como si estuviera verificando la instancia del temporizador ya existente al principio, pero no es correcto, porque no hay protecci\u00f3n, por lo tanto, cualquier llamada simult\u00e1nea posterior a snd_seq_timer_open() puede anular la instancia del temporizador f\u00e1cilmente. Esto puede resultar en UAF, ya que la instancia del temporizador sobrante puede seguir ejecut\u00e1ndose mientras la cola se cierra, como descubri\u00f3 syzkaller recientemente. Para evitar la ejecuci\u00f3n, agregue una verificaci\u00f3n adecuada en la asignaci\u00f3n de tmr->timeri nuevamente y devuelva -EBUSY si ya se registr\u00f3."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: bcm2835: Fix out-of-bounds access with more than 4 slaves\n\nCommit 571e31fa60b3 (\"spi: bcm2835: Cache CS register value for\n->prepare_message()\") limited the number of slaves to 3 at compile-time.\nThe limitation was necessitated by a statically-sized array prepare_cs[]\nin the driver private data which contains a per-slave register value.\n\nThe commit sought to enforce the limitation at run-time by setting the\ncontroller's num_chipselect to 3: Slaves with a higher chipselect are\nrejected by spi_add_device().\n\nHowever the commit neglected that num_chipselect only limits the number\nof *native* chipselects. If GPIO chipselects are specified in the\ndevice tree for more than 3 slaves, num_chipselect is silently raised by\nof_spi_get_gpio_numbers() and the result are out-of-bounds accesses to\nthe statically-sized array prepare_cs[].\n\nAs a bandaid fix which is backportable to stable, raise the number of\nallowed slaves to 24 (which \"ought to be enough for anybody\"), enforce\nthe limitation on slave ->setup and revert num_chipselect to 3 (which is\nthe number of native chipselects supported by the controller).\nAn upcoming for-next commit will allow an arbitrary number of slaves."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: bcm2835: corrige el acceso fuera de los l\u00edmites con m\u00e1s de 4 esclavos. La confirmaci\u00f3n 571e31fa60b3 (\"spi: bcm2835: valor de registro CS de cach\u00e9 para ->prepare_message()\") limit\u00f3 el n\u00famero de esclavos a 3 en tiempo de compilaci\u00f3n. La limitaci\u00f3n fue necesaria por una matriz de tama\u00f1o est\u00e1tico prepare_cs[] en los datos privados del controlador que contiene un valor de registro por esclavo. La confirmaci\u00f3n buscaba hacer cumplir la limitaci\u00f3n en tiempo de ejecuci\u00f3n estableciendo num_chipselect del controlador en 3: spi_add_device() rechaza los esclavos con una selecci\u00f3n de chip m\u00e1s alta. Sin embargo, la confirmaci\u00f3n omiti\u00f3 que num_chipselect solo limita el n\u00famero de selecciones de chips *nativas*. Si se especifican selecciones de chips GPIO en el \u00e1rbol de dispositivos para m\u00e1s de 3 esclavos, of_spi_get_gpio_numbers() genera silenciosamente num_chipselect y el resultado son accesos fuera de los l\u00edmites a la matriz de tama\u00f1o est\u00e1tico prepare_cs[]. Como soluci\u00f3n curita que se puede volver a transferir a estable, aumente la cantidad de esclavos permitidos a 24 (lo que \"deber\u00eda ser suficiente para cualquiera\"), aplique la limitaci\u00f3n en esclavo -> configuraci\u00f3n y revierta num_chipselect a 3 (que es la cantidad de nativos selecciones de chips admitidas por el controlador). Una pr\u00f3xima confirmaci\u00f3n para la pr\u00f3xima permitir\u00e1 una cantidad arbitraria de esclavos."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet:sfc: fix non-freed irq in legacy irq mode\n\nSFC driver can be configured via modparam to work using MSI-X, MSI or\nlegacy IRQ interrupts. In the last one, the interrupt was not properly\nreleased on module remove.\n\nIt was not freed because the flag irqs_hooked was not set during\ninitialization in the case of using legacy IRQ.\n\nExample of (trimmed) trace during module remove without this fix:\n\nremove_proc_entry: removing non-empty directory 'irq/125', leaking at least '0000:3b:00.1'\nWARNING: CPU: 39 PID: 3658 at fs/proc/generic.c:715 remove_proc_entry+0x15c/0x170\n...trimmed...\nCall Trace:\n unregister_irq_proc+0xe3/0x100\n free_desc+0x29/0x70\n irq_free_descs+0x47/0x70\n mp_unmap_irq+0x58/0x60\n acpi_unregister_gsi_ioapic+0x2a/0x40\n acpi_pci_irq_disable+0x78/0xb0\n pci_disable_device+0xd1/0x100\n efx_pci_remove+0xa1/0x1e0 [sfc]\n pci_device_remove+0x38/0xa0\n __device_release_driver+0x177/0x230\n driver_detach+0xcb/0x110\n bus_remove_driver+0x58/0xd0\n pci_unregister_driver+0x2a/0xb0\n efx_exit_module+0x24/0xf40 [sfc]\n __do_sys_delete_module.constprop.0+0x171/0x280\n ? exit_to_user_mode_prepare+0x83/0x1d0\n do_syscall_64+0x3d/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f9f9385800b\n...trimmed..."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net:sfc: corrige irq no liberado en modo irq heredado. El controlador SFC se puede configurar mediante modparam para que funcione usando interrupciones MSI-X, MSI o IRQ heredadas. En el \u00faltimo, la interrupci\u00f3n no se liber\u00f3 correctamente al eliminar el m\u00f3dulo. No se liber\u00f3 porque el indicador irqs_hooked no se estableci\u00f3 durante la inicializaci\u00f3n en el caso de utilizar IRQ heredado. Ejemplo de seguimiento (recortado) durante la eliminaci\u00f3n del m\u00f3dulo sin esta soluci\u00f3n: remove_proc_entry: eliminando el directorio no vac\u00edo 'irq/125', filtrando al menos '0000:3b:00.1' ADVERTENCIA: CPU: 39 PID: 3658 en fs/proc/generic .c:715 remove_proc_entry+0x15c/0x170 ...recortado... Seguimiento de llamadas: unregister_irq_proc+0xe3/0x100 free_desc+0x29/0x70 irq_free_descs+0x47/0x70 mp_unmap_irq+0x58/0x60 acpi_unregister_gsi_ioapic+0x2a/0x 40 acpi_pci_irq_disable+0x78/0xb0 pci_disable_device +0xd1/0x100 efx_pci_remove+0xa1/0x1e0 [sfc] pci_device_remove+0x38/0xa0 __device_release_driver+0x177/0x230 driver_detach+0xcb/0x110 bus_remove_driver+0x58/0xd0 pci_unregister_driver+0x2a/0 xb0 efx_exit_module+0x24/0xf40 [sfc] __do_sys_delete_module.constprop.0 +0x171/0x280 ? exit_to_user_mode_prepare+0x83/0x1d0 do_syscall_64+0x3d/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f9f9385800b ...recortado..."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nisdn: mISDN: netjet: Fix crash in nj_probe:\n\n'nj_setup' in netjet.c might fail with -EIO and in this case\n'card->irq' is initialized and is bigger than zero. A subsequent call to\n'nj_release' will free the irq that has not been requested.\n\nFix this bug by deleting the previous assignment to 'card->irq' and just\nkeep the assignment before 'request_irq'.\n\nThe KASAN's log reveals it:\n\n[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826\nfree_irq+0x100/0x480\n[ 3.355112 ] Modules linked in:\n[ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 3.356552 ] RIP: 0010:free_irq+0x100/0x480\n[ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18\n4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5\nff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80\n[ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082\n[ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:\n0000000000000000\n[ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:\n00000000ffffffff\n[ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:\n0000000000000000\n[ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:\n0000000000000000\n[ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:\nffff888104dc80a8\n[ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)\nknlGS:0000000000000000\n[ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:\n00000000000006f0\n[ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[ 3.362175 ] Call Trace:\n[ 3.362175 ] nj_release+0x51/0x1e0\n[ 3.362175 ] nj_probe+0x450/0x950\n[ 3.362175 ] ? pci_device_remove+0x110/0x110\n[ 3.362175 ] local_pci_probe+0x45/0xa0\n[ 3.362175 ] pci_device_probe+0x12b/0x1d0\n[ 3.362175 ] really_probe+0x2a9/0x610\n[ 3.362175 ] driver_probe_device+0x90/0x1d0\n[ 3.362175 ] ? mutex_lock_nested+0x1b/0x20\n[ 3.362175 ] device_driver_attach+0x68/0x70\n[ 3.362175 ] __driver_attach+0x124/0x1b0\n[ 3.362175 ] ? device_driver_attach+0x70/0x70\n[ 3.362175 ] bus_for_each_dev+0xbb/0x110\n[ 3.362175 ] ? rdinit_setup+0x45/0x45\n[ 3.362175 ] driver_attach+0x27/0x30\n[ 3.362175 ] bus_add_driver+0x1eb/0x2a0\n[ 3.362175 ] driver_register+0xa9/0x180\n[ 3.362175 ] __pci_register_driver+0x82/0x90\n[ 3.362175 ] ? w6692_init+0x38/0x38\n[ 3.362175 ] nj_init+0x36/0x38\n[ 3.362175 ] do_one_initcall+0x7f/0x3d0\n[ 3.362175 ] ? rdinit_setup+0x45/0x45\n[ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80\n[ 3.362175 ] kernel_init_freeable+0x2aa/0x301\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] kernel_init+0x18/0x190\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] ret_from_fork+0x1f/0x30\n[ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...\n[ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 3.362175 ] Call Trace:\n[ 3.362175 ] dump_stack+0xba/0xf5\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] panic+0x15a/0x3f2\n[ 3.362175 ] ? __warn+0xf2/0x150\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] __warn+0x108/0x150\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] report_bug+0x119/0x1c0\n[ 3.362175 ] handle_bug+0x3b/0x80\n[ 3.362175 ] exc_invalid_op+0x18/0x70\n[ 3.362175 ] asm_exc_invalid_op+0x12/0x20\n[ 3.362175 ] RIP: 0010:free_irq+0x100\n---truncated---"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: isdn: mISDN: netjet: Soluciona fallo en nj_probe: 'nj_setup' en netjet.c puede fallar con -EIO y en este caso 'card->irq' est\u00e1 inicializado y es m\u00e1s grande que cero. Una llamada posterior a 'nj_release' liberar\u00e1 el irq que no ha sido solicitado. Corrija este error eliminando la asignaci\u00f3n anterior a 'card->irq' y simplemente mantenga la asignaci\u00f3n antes de 'request_irq'. El registro de KASAN lo revela: [3.354615] ADVERTENCIA: CPU: 0 PID: 1 en kernel/irq/manage.c:1826 free_irq+0x100/0x480 [3.355112] M\u00f3dulos vinculados en: [3.355310] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.355816 ] Nombre del hardware: PC est\u00e1ndar QEMU (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04 /01/2014 [ 3.356552 ] RIP: 0010:free_irq+0x100/0x480 [ 3.356820 ] C\u00f3digo: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80 [ 3.358012 ] RSP: 17b48 EFLAGS: 00010082 [ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX: 0000000000000000 [ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI: 00000000ffffff ff [ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09: 0000000000000000 [ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d0 4 R12: 0000000000000000 [ 3.360195 ] R13 : ffff888107dc6000 R14: ffff888107dc6928 R15: ffff888104dc80a8 [ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000) 00000000000 [ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.361538 ] CR2: 00000000000000000 CR3: 000000000582e000 CR4: 00000000000006f0 [ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.362175 ] DR3: 000000000000000 0 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.362175 ] Seguimiento de llamadas: [ 3.362175 ] nj_release+0x51/0x1e0 [ 3.362175 ] nj_probe+0x450/0x950 [ 3,362175 ] ? pci_device_remove+0x110/0x110 [ 3.362175 ] local_pci_probe+0x45/0xa0 [ 3.362175 ] pci_device_probe+0x12b/0x1d0 [ 3.362175 ] really_probe+0x2a9/0x610 [ 3.362175 ]driver_probe_device+0x90/0x1d0 [3.362175]? mutex_lock_nested+0x1b/0x20 [3.362175] device_driver_attach+0x68/0x70 [3.362175] __driver_attach+0x124/0x1b0 [3.362175]? device_driver_attach+0x70/0x70 [3.362175] bus_for_each_dev+0xbb/0x110 [3.362175]? rdinit_setup+0x45/0x45 [ 3.362175 ] driver_attach+0x27/0x30 [ 3.362175 ] bus_add_driver+0x1eb/0x2a0 [ 3.362175 ] driver_register+0xa9/0x180 [ 3.362175 ] x82/0x90 [3.362175]? w6692_init+0x38/0x38 [3.362175] nj_init+0x36/0x38 [3.362175] do_one_initcall+0x7f/0x3d0 [3.362175]? rdinit_setup+0x45/0x45 [3.362175]? rcu_read_lock_sched_held+0x4f/0x80 [3.362175] kernel_init_freeable+0x2aa/0x301 [3.362175]? rest_init+0x2c0/0x2c0 [3.362175] kernel_init+0x18/0x190 [3.362175]? rest_init+0x2c0/0x2c0 [3.362175]? rest_init+0x2c0/0x2c0 [3.362175] ret_from_fork+0x1f/0x30 [3.362175] P\u00e1nico del kernel - no sincronizado: panic_on_warn establecido... [3.362175] CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.13.0-rc1-00144 -g25a1298726e #13 [ 3.362175 ] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 01/04/2014 [ 3.362175 ] Seguimiento de llamadas: [ 3.362175 ] dump_stack+0xba/0xf5 [3.362175]? free_irq+0x100/0x480 [3.362175] p\u00e1nico+0x15a/0x3f2 [3.362175]? __advertir+0xf2/0x150 [3.362175]? free_irq+0x100/0x480 [3.362175] __warn+0x108/0x150 [3.362175]? free_irq+0x100/0x480 [ 3.362175 ] report_bug+0x119/0x1c0 [ 3.362175 ] handle_bug+0x3b/0x80 [ 3.362175 ] exc_invalid_op+0x18/0x70 [ 3.362175 ] x12/0x20 [3.362175] RIP: 0010:free_irq+0x100 --- truncado---"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/nfc/rawsock.c: fix a permission check bug\n\nThe function rawsock_create() calls a privileged function sk_alloc(), which requires a ns-aware check to check net->user_ns, i.e., ns_capable(). However, the original code checks the init_user_ns using capable(). So we replace the capable() with ns_capable()."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/nfc/rawsock.c: corrige un error de verificaci\u00f3n de permisos. La funci\u00f3n rawsock_create() llama a una funci\u00f3n privilegiada sk_alloc(), que requiere una verificaci\u00f3n ns-aware para verificar net-> user_ns, es decir, ns_capable(). Sin embargo, el c\u00f3digo original verifica init_user_ns usando able(). Entonces reemplazamos el capaz() con ns_capable()."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: core: Validate channel ID when processing command completions\n\nMHI reads the channel ID from the event ring element sent by the\ndevice which can be any value between 0 and 255. In order to\nprevent any out of bound accesses, add a check against the maximum\nnumber of channels supported by the controller and those channels\nnot configured yet so as to skip processing of that event ring\nelement."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: core: valida el ID del canal al procesar la finalizaci\u00f3n del comando MHI lee el ID del canal del elemento del anillo de eventos enviado por el dispositivo, que puede tener cualquier valor entre 0 y 255. Para evitar accesos fuera de los l\u00edmites, agregue una verificaci\u00f3n del n\u00famero m\u00e1ximo de canales admitidos por el controlador y aquellos canales que a\u00fan no est\u00e1n configurados para omitir el procesamiento de ese elemento del anillo de eventos."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: auxiliary bus: Fix memory leak when driver_register() fail\n\nIf driver_register() returns with error we need to free the memory\nallocated for auxdrv->driver.name before returning from\n__auxiliary_driver_register()"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: n\u00facleo del controlador: bus auxiliar: corrige la p\u00e9rdida de memoria cuando falla driver_register(). Si driver_register() regresa con error, necesitamos liberar la memoria asignada para auxdrv->driver.name antes de regresar de __auxiliary_driver_register()"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()\n\nFix an 11-year old bug in ngene_command_config_free_buf() while\naddressing the following warnings caught with -Warray-bounds:\n\narch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]\narch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]\n\nThe problem is that the original code is trying to copy 6 bytes of\ndata into a one-byte size member _config_ of the wrong structue\nFW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a\nlegitimate compiler warning because memcpy() overruns the length\nof &com.cmd.ConfigureBuffers.config. It seems that the right\nstructure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains\n6 more members apart from the header _hdr_. Also, the name of\nthe function ngene_command_config_free_buf() suggests that the actual\nintention is to ConfigureFreeBuffers, instead of ConfigureBuffers\n(which takes place in the function ngene_command_config_buf(), above).\n\nFix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS\ninto new struct config, and use &com.cmd.ConfigureFreeBuffers.config as\nthe destination address, instead of &com.cmd.ConfigureBuffers.config,\nwhen calling memcpy().\n\nThis also helps with the ongoing efforts to globally enable\n-Warray-bounds and get us closer to being able to tighten the\nFORTIFY_SOURCE routines on memcpy()."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: medios: ngene: corrige un error fuera de los l\u00edmites en ngene_command_config_free_buf(). Corrige un error de hace 11 a\u00f1os en ngene_command_config_free_buf() mientras se solucionan las siguientes advertencias detectadas con -Warray-bounds: arch/alpha/include/asm/string.h:22:16: advertencia: el desplazamiento '__builtin_memcpy' [12, 16] del objeto en 'com' est\u00e1 fuera de los l\u00edmites del subobjeto referenciado 'config' con tipo 'car\u00e1cter sin firmar ' en el desplazamiento 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: advertencia: el desplazamiento '__builtin_memcpy' [12, 16] del objeto en 'com' est\u00e1 fuera de los l\u00edmites de subobjeto referenciado 'config' con tipo 'unsigned char' en el desplazamiento 10 [-Warray-bounds] El problema es que el c\u00f3digo original est\u00e1 intentando copiar 6 bytes de datos en un miembro de tama\u00f1o de un byte _config_ de la estructura incorrecta FW_CONFIGURE_BUFFERS, en una sola llamada a memcpy(). Esto provoca una advertencia leg\u00edtima del compilador porque memcpy() sobrepasa la longitud de &com.cmd.ConfigureBuffers.config. Parece que la estructura correcta es FW_CONFIGURE_FREE_BUFFERS, porque contiene 6 miembros m\u00e1s adem\u00e1s del encabezado _hdr_. Adem\u00e1s, el nombre de la funci\u00f3n ngene_command_config_free_buf() sugiere que la intenci\u00f3n real es ConfigureFreeBuffers, en lugar de ConfigureBuffers (que tiene lugar en la funci\u00f3n ngene_command_config_buf(), arriba). Solucione este problema encerrando esos 6 miembros de la estructura FW_CONFIGURE_FREE_BUFFERS en una nueva configuraci\u00f3n de estructura y use &com.cmd.ConfigureFreeBuffers.config como direcci\u00f3n de destino, en lugar de &com.cmd.ConfigureBuffers.config, al llamar a memcpy(). Esto tambi\u00e9n ayuda con los esfuerzos continuos para habilitar globalmente -Warray-bounds y acercarnos a poder ajustar las rutinas FORTIFY_SOURCE en memcpy()."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: fix NULL pointer dereference\n\nCommit 71f642833284 (\"ACPI: utils: Fix reference counting in\nfor_each_acpi_dev_match()\") started doing \"acpi_dev_put()\" on a pointer\nthat was possibly NULL. That fails miserably, because that helper\ninline function is not set up to handle that case.\n\nJust make acpi_dev_put() silently accept a NULL pointer, rather than\ncalling down to put_device() with an invalid offset off that NULL\npointer."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: ACPI: corrige la desreferencia del puntero NULL. La confirmaci\u00f3n 71f642833284 (\"ACPI: utils: corrige el recuento de referencias en for_each_acpi_dev_match()\") comenz\u00f3 a hacer \"acpi_dev_put()\" en un puntero que posiblemente era NULL. Eso falla estrepitosamente, porque esa funci\u00f3n auxiliar en l\u00ednea no est\u00e1 configurada para manejar ese caso. Simplemente haga que acpi_dev_put() acepte silenciosamente un puntero NULL, en lugar de llamar a put_device() con un desplazamiento no v\u00e1lido de ese puntero NULL."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Fix NULL dereference on XCOPY completion\n\nCPU affinity control added with commit 39ae3edda325 (\"scsi: target: core:\nMake completion affinity configurable\") makes target_complete_cmd() queue\nwork on a CPU based on se_tpg->se_tpg_wwn->cmd_compl_affinity state.\n\nLIO's EXTENDED COPY worker is a special case in that read/write cmds are\ndispatched using the global xcopy_pt_tpg, which carries a NULL se_tpg_wwn\npointer following initialization in target_xcopy_setup_pt().\n\nThe NULL xcopy_pt_tpg->se_tpg_wwn pointer is dereferenced on completion of\nany EXTENDED COPY initiated read/write cmds. E.g using the libiscsi\nSCSI.ExtendedCopy.Simple test:\n\n BUG: kernel NULL pointer dereference, address: 00000000000001a8\n RIP: 0010:target_complete_cmd+0x9d/0x130 [target_core_mod]\n Call Trace:\n fd_execute_rw+0x148/0x42a [target_core_file]\n ? __dynamic_pr_debug+0xa7/0xe0\n ? target_check_reservation+0x5b/0x940 [target_core_mod]\n __target_execute_cmd+0x1e/0x90 [target_core_mod]\n transport_generic_new_cmd+0x17c/0x330 [target_core_mod]\n target_xcopy_issue_pt_cmd+0x9/0x60 [target_core_mod]\n target_xcopy_read_source.isra.7+0x10b/0x1b0 [target_core_mod]\n ? target_check_fua+0x40/0x40 [target_core_mod]\n ? transport_complete_task_attr+0x130/0x130 [target_core_mod]\n target_xcopy_do_work+0x61f/0xc00 [target_core_mod]\n\nThis fix makes target_complete_cmd() queue work on se_cmd->cpuid if\nse_tpg_wwn is NULL."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: corrige la desreferencia NULL al completar XCOPY. El control de afinidad de CPU agregado con la confirmaci\u00f3n 39ae3edda325 (\"scsi: target: core: hace que la afinidad de finalizaci\u00f3n sea configurable\") hace que la cola target_complete_cmd() funcione una CPU basada en el estado se_tpg->se_tpg_wwn->cmd_compl_affinity. El trabajador de COPIA EXTENDIDA de LIO es un caso especial en el que los cmds de lectura/escritura se env\u00edan utilizando el xcopy_pt_tpg global, que lleva un puntero NULL se_tpg_wwn despu\u00e9s de la inicializaci\u00f3n en target_xcopy_setup_pt(). Se elimina la referencia al puntero NULL xcopy_pt_tpg->se_tpg_wwn al finalizar cualquier cmd de lectura/escritura iniciado por COPIA EXTENDIDA. Por ejemplo, utilizando la prueba libiscsi SCSI.ExtendedCopy.Simple: BUG: desreferencia del puntero NULL del kernel, direcci\u00f3n: 00000000000001a8 RIP: 0010:target_complete_cmd+0x9d/0x130 [target_core_mod] Seguimiento de llamadas: fd_execute_rw+0x148/0x42a [target_core_file] __dynamic_pr_debug+0xa7/0xe0? target_check_reservation+0x5b/0x940 [target_core_mod] __target_execute_cmd+0x1e/0x90 [target_core_mod] transport_generic_new_cmd+0x17c/0x330 [target_core_mod] target_xcopy_issue_pt_cmd+0x9/0x60 [target_core_mod] target_xcopy_read_source.isra.7 +0x10b/0x1b0 [target_core_mod] ? target_check_fua+0x40/0x40 [target_core_mod]? transport_complete_task_attr+0x130/0x130 [target_core_mod] target_xcopy_do_work+0x61f/0xc00 [target_core_mod] Esta soluci\u00f3n hace que la cola target_complete_cmd() funcione en se_cmd->cpuid si se_tpg_wwn es NULL."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix another slab-out-of-bounds in fib6_nh_flush_exceptions\n\nWhile running the self-tests on a KASAN enabled kernel, I observed a\nslab-out-of-bounds splat very similar to the one reported in\ncommit 821bbf79fe46 (\"ipv6: Fix KASAN: slab-out-of-bounds Read in\n fib6_nh_flush_exceptions\").\n\nWe additionally need to take care of fib6_metrics initialization\nfailure when the caller provides an nh.\n\nThe fix is similar, explicitly free the route instead of calling\nfib6_info_release on a half-initialized object."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: ipv6: corrige otra slab fuera de los l\u00edmites en fib6_nh_flush_exceptions. Mientras ejecutaba las autopruebas en un kernel habilitado para KASAN, observ\u00e9 una slab fuera de los l\u00edmites muy similar al informado en la confirmaci\u00f3n 821bbf79fe46 (\"ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions\"). Adem\u00e1s, debemos ocuparnos del error de inicializaci\u00f3n de fib6_metrics cuando la persona que llama proporciona un nh. La soluci\u00f3n es similar: libera expl\u00edcitamente la ruta en lugar de llamar a fib6_info_release en un objeto medio inicializado."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix memleak in io_init_wq_offload()\n\nI got memory leak report when doing fuzz test:\n\nBUG: memory leak\nunreferenced object 0xffff888107310a80 (size 96):\ncomm \"syz-executor.6\", pid 4610, jiffies 4295140240 (age 20.135s)\nhex dump (first 32 bytes):\n01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........\nbacktrace:\n[<000000001974933b>] kmalloc include/linux/slab.h:591 [inline]\n[<000000001974933b>] kzalloc include/linux/slab.h:721 [inline]\n[<000000001974933b>] io_init_wq_offload fs/io_uring.c:7920 [inline]\n[<000000001974933b>] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955\n[<0000000039d0800d>] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016\n[<000000008482e78c>] io_uring_add_tctx_node fs/io_uring.c:9052 [inline]\n[<000000008482e78c>] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline]\n[<000000008482e78c>] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline]\n[<000000008482e78c>] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301\n[<00000000b875f18f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n[<00000000b875f18f>] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n[<000000006b0a8484>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nCPU0 CPU1\nio_uring_enter io_uring_enter\nio_uring_add_tctx_node io_uring_add_tctx_node\n__io_uring_add_tctx_node __io_uring_add_tctx_node\nio_uring_alloc_task_context io_uring_alloc_task_context\nio_init_wq_offload io_init_wq_offload\nhash = kzalloc hash = kzalloc\nctx->hash_map = hash ctx->hash_map = hash <- one of the hash is leaked\n\nWhen calling io_uring_enter() in parallel, the 'hash_map' will be leaked,\nadd uring_lock to protect 'hash_map'."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: io_uring: corrige memleak en io_init_wq_offload(). Recib\u00ed un informe de p\u00e9rdida de memoria al realizar la prueba fuzz: BUG: p\u00e9rdida de memoria objeto sin referencia 0xffff888107310a80 (tama\u00f1o 96): comm \"syz-executor.6\" , pid 4610, sjiffies 4295140240 (edad 20,135 s) volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................. 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<000000001974933b>] kmalloc include/linux/slab.h:591 [en l\u00ednea] [<000000001974933b>] kzalloc include/linux/slab.h:721 [en l\u00ednea] [<000000001974933b>] io_init_wq_offload fs/io_uring.c:7920 [en l\u00ednea] [<000000001974933b>] _context+0x466/0x640 fs/io_uring .c:7955 [<0000000039d0800d>] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016 [<000000008482e78c>] io_uring_add_tctx_node fs/io_uring.c:9052 [en l\u00ednea] 0000008482e78c>] __do_sys_io_uring_enter fs/io_uring.c:9354 [en l\u00ednea] [<000000008482e78c>] __se_sys_io_uring_enter fs/io_uring.c:9301 [en l\u00ednea] [<000000008482e78c>] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301 [<00000000b 875f18f>] do_syscall_x64 arch/x86/entry/common. c:50 [en l\u00ednea] [<00000000b875f18f>] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 [<000000006b0a8484>] Entry_SYSCALL_64_after_hwframe+0x44/0xae CPU0 CPU1 io_uring_enter io_uring_enter io_uring_add_tctx_node io_uring_add_tctx_node __io_uring_add_tctx_node __io_uring_add_tctx_node io_uring_alloc_task_context io_uring_alloc_task_context io_init_wq_offload io_init_wq_offload hash = kzalloc hash = kzalloc ctx->hash_map = hash ctx->hash_map = hash <- uno de los hash se filtra Al llamar a io_uring_enter() en paralelo, se filtrar\u00e1 el 'hash_map', agregue uring_lock para proteger 'hash_map'."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_skbmod: Skip non-Ethernet packets\n\nCurrently tcf_skbmod_act() assumes that packets use Ethernet as their L2\nprotocol, which is not always the case. As an example, for CAN devices:\n\n\t$ ip link add dev vcan0 type vcan\n\t$ ip link set up vcan0\n\t$ tc qdisc add dev vcan0 root handle 1: htb\n\t$ tc filter add dev vcan0 parent 1: protocol ip prio 10 \\\n\t\tmatchall action skbmod swap mac\n\nDoing the above silently corrupts all the packets. Do not perform skbmod\nactions for non-Ethernet packets."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_skbmod: omitir paquetes que no sean Ethernet. Actualmente, tcf_skbmod_act() asume que los paquetes usan Ethernet como protocolo L2, lo cual no siempre es el caso. Como ejemplo, para dispositivos CAN: $ ip link add dev vcan0 type vcan $ ip link set up vcan0 $ tc qdisc add dev vcan0 root handle 1: htb $ tc filter add dev vcan0 parent 1: protocolo ip prio 10 \\ matchall action skbmod swap mac Hacer lo anterior corrompe silenciosamente todos los paquetes. No realice acciones de skbmod para paquetes que no sean Ethernet."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: Decrease sock refcount when sock timers expire\n\nCommit 63346650c1a9 (\"netrom: switch to sock timer API\") switched to use\nsock timer API. It replaces mod_timer() by sk_reset_timer(), and\ndel_timer() by sk_stop_timer().\n\nFunction sk_reset_timer() will increase the refcount of sock if it is\ncalled on an inactive timer, hence, in case the timer expires, we need to\ndecrease the refcount ourselves in the handler, otherwise, the sock\nrefcount will be unbalanced and the sock will never be freed."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: netrom: Disminuir el recuento de sock cuando caducan los temporizadores de sock. La confirmaci\u00f3n 63346650c1a9 (\"netrom: cambiar a API de temporizador de sock\") cambi\u00f3 para usar la API de temporizador de sock. Reemplaza mod_timer() por sk_reset_timer() y del_timer() por sk_stop_timer(). La funci\u00f3n sk_reset_timer() aumentar\u00e1 el recuento del sock si se llama en un temporizador inactivo, por lo tanto, en caso de que el temporizador expire, debemos disminuir el recuento nosotros mismos en el controlador; de lo contrario, el recuento del calcet\u00edn se desequilibrar\u00e1 y el sock nunca ser\u00e1 liberado."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: fix memory leak in tcindex_partial_destroy_work\n\nSyzbot reported memory leak in tcindex_set_parms(). The problem was in\nnon-freed perfect hash in tcindex_partial_destroy_work().\n\nIn tcindex_set_parms() new tcindex_data is allocated and some fields from\nold one are copied to new one, but not the perfect hash. Since\ntcindex_partial_destroy_work() is the destroy function for old\ntcindex_data, we need to free perfect hash to avoid memory leak."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net: sched: corrige la p\u00e9rdida de memoria en tcindex_partial_destroy_work Syzbot inform\u00f3 una p\u00e9rdida de memoria en tcindex_set_parms(). El problema estaba en el hash perfecto no liberado en tcindex_partial_destroy_work(). En tcindex_set_parms() se asigna un nuevo tcindex_data y algunos campos del anterior se copian al nuevo, pero no el hash perfecto. Dado que tcindex_partial_destroy_work() es la funci\u00f3n de destrucci\u00f3n del antiguo tcindex_data, necesitamos liberar un hash perfecto para evitar p\u00e9rdidas de memoria."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak\n\nvcpu_put is not called if the user copy fails. This can result in preempt\nnotifier corruption and crashes, among other issues."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: PPC: correcci\u00f3n de fuga de kvm_arch_vcpu_ioctl vcpu_load. No se llama a vcpu_put si falla la copia del usuario. Esto puede provocar da\u00f1os y bloqueos del notificador preventivo, entre otros problemas."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix uninit-value in caif_seqpkt_sendmsg\n\nWhen nr_segs equal to zero in iovec_from_user, the object\nmsg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg\nwhich is defined in ___sys_sendmsg. So we cann't just judge\nmsg->msg_iter.iov->base directlly. We can use nr_segs to judge\nmsg in caif_seqpkt_sendmsg whether has data buffers.\n\n=====================================================\nBUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x1c9/0x220 lib/dump_stack.c:118\n kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118\n __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215\n caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542\n sock_sendmsg_nosec net/socket.c:652 [inline]\n sock_sendmsg net/socket.c:672 [inline]\n ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343\n ___sys_sendmsg net/socket.c:2397 [inline]\n __sys_sendmmsg+0x808/0xc90 net/socket.c:2480\n __compat_sys_sendmmsg net/compat.c:656 [inline]"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net: corrige el valor uninit en caif_seqpkt_sendmsg. Cuando nr_segs es igual a cero en iovec_from_user, el objeto msg->msg_iter.iov es la memoria de pila uninit en caif_seqpkt_sendmsg que est\u00e1 definida en ___sys_sendmsg. Entonces no podemos simplemente juzgar msg->msg_iter.iov->base directamente. Podemos usar nr_segs para juzgar si msg en caif_seqpkt_sendmsg tiene buffers de datos. ==================================================== === BUG: KMSAN: valor uninit en caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:77 [en l\u00ednea] dump_stack+0x1c9/0x220 lib/dump_stack.c: 118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 sock_sendmsg_nosec net/so cket.c: 652 [en l\u00ednea] sock_sendmsg net/socket.c:672 [en l\u00ednea] ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343 ___sys_sendmsg net/socket.c:2397 [en l\u00ednea] __sys_sendmmsg+0x808/0xc90 80 __compat_sys_sendmmsg net/compat.c:656 [en l\u00ednea]"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix potential memory leak on unlikely error case\n\nIf skb_linearize is needed and fails we could leak a msg on the error\nhandling. To fix ensure we kfree the msg block before returning error.\nFound during code review."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: bpf, sockmap: corrige una posible p\u00e9rdida de memoria en un caso de error poco probable. Si se necesita skb_linearize y falla, podr\u00edamos filtrar un mensaje sobre el manejo de errores. Para solucionarlo, aseg\u00farese de liberar el bloque de mensajes antes de devolver el error. Encontrado durante la revisi\u00f3n del c\u00f3digo."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxdp, net: Fix use-after-free in bpf_xdp_link_release\n\nThe problem occurs between dev_get_by_index() and dev_xdp_attach_link().\nAt this point, dev_xdp_uninstall() is called. Then xdp link will not be\ndetached automatically when dev is released. But link->dev already\npoints to dev, when xdp link is released, dev will still be accessed,\nbut dev has been released.\n\ndev_get_by_index() |\nlink->dev = dev |\n | rtnl_lock()\n | unregister_netdevice_many()\n | dev_xdp_uninstall()\n | rtnl_unlock()\nrtnl_lock(); |\ndev_xdp_attach_link() |\nrtnl_unlock(); |\n | netdev_run_todo() // dev released\nbpf_xdp_link_release() |\n /* access dev. |\n use-after-free */ |\n\n[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0\n[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732\n[ 45.968297]\n[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22\n[ 45.969222] Hardware name: linux,dummy-virt (DT)\n[ 45.969795] Call trace:\n[ 45.970106] dump_backtrace+0x0/0x4c8\n[ 45.970564] show_stack+0x30/0x40\n[ 45.970981] dump_stack_lvl+0x120/0x18c\n[ 45.971470] print_address_description.constprop.0+0x74/0x30c\n[ 45.972182] kasan_report+0x1e8/0x200\n[ 45.972659] __asan_report_load8_noabort+0x2c/0x50\n[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0\n[ 45.973834] bpf_link_free+0xd0/0x188\n[ 45.974315] bpf_link_put+0x1d0/0x218\n[ 45.974790] bpf_link_release+0x3c/0x58\n[ 45.975291] __fput+0x20c/0x7e8\n[ 45.975706] ____fput+0x24/0x30\n[ 45.976117] task_work_run+0x104/0x258\n[ 45.976609] do_notify_resume+0x894/0xaf8\n[ 45.977121] work_pending+0xc/0x328\n[ 45.977575]\n[ 45.977775] The buggy address belongs to the page:\n[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998\n[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)\n[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000\n[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n[ 45.982259] page dumped because: kasan: bad access detected\n[ 45.982948]\n[ 45.983153] Memory state around the buggy address:\n[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[ 45.986419] ^\n[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[ 45.988895] ==================================================================\n[ 45.989773] Disabling lock debugging due to kernel taint\n[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...\n[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22\n[ 45.991929] Hardware name: linux,dummy-virt (DT)\n[ 45.992448] Call trace:\n[ 45.992753] dump_backtrace+0x0/0x4c8\n[ 45.993208] show_stack+0x30/0x40\n[ 45.993627] dump_stack_lvl+0x120/0x18c\n[ 45.994113] dump_stack+0x1c/0x34\n[ 45.994530] panic+0x3a4/0x7d8\n[ 45.994930] end_report+0x194/0x198\n[ 45.995380] kasan_report+0x134/0x200\n[ 45.995850] __asan_report_load8_noabort+0x2c/0x50\n[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0\n[ 45.997007] bpf_link_free+0xd0/0x188\n[ 45.997474] bpf_link_put+0x1d0/0x218\n[ 45.997942] bpf_link_release+0x3c/0x58\n[ 45.998429] __fput+0x20c/0x7e8\n[ 45.998833] ____fput+0x24/0x30\n[ 45.999247] task_work_run+0x104/0x258\n[ 45.999731] do_notify_resume+0x894/0xaf8\n[ 46.000236] work_pending\n---truncated---"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: xdp, net: corrige use-after-free en bpf_xdp_link_release. El problema ocurre entre dev_get_by_index() y dev_xdp_attach_link(). En este punto, se llama a dev_xdp_uninstall(). Entonces el enlace xdp no se desconectar\u00e1 autom\u00e1ticamente cuando se libere el desarrollador. Pero link->dev ya apunta a dev, cuando se libera el enlace xdp, se seguir\u00e1 accediendo a dev, pero se ha liberado. dev_get_by_index() | enlace->dev = dev | | rtnl_lock() | unregister_netdevice_many() | dev_xdp_uninstall() | rtnl_unlock() rtnl_lock(); | dev_xdp_attach_link() | rtnl_unlock(); | | netdev_run_todo() // desarrollador liberado bpf_xdp_link_release() | /* accede al desarrollador. | use after free */ | [45.966867] BUG: KASAN: use after free en bpf_xdp_link_release+0x3b8/0x3d0 [45.967619] Lectura del tama\u00f1o 8 en la direcci\u00f3n ffff00000f9980c8 por tarea a.out/732 [45.968297] [45.968502] CPU: 1 PID: Comunicaciones 732: un .out No contaminado 5.13.0+ #22 [ 45.969222] Nombre de hardware: linux,dummy-virt (DT) [ 45.969795] Seguimiento de llamadas: [ 45.970106] dump_backtrace+0x0/0x4c8 [ 45.970564] show_stack+0x30/0x40 [ 45.970981 ] dump_stack_lvl +0x120/0x18c [ 45.971470] print_address_description.constprop.0+0x74/0x30c [ 45.972182] kasan_report+0x1e8/0x200 [ 45.972659] __asan_report_load8_noabort+0x2c/0x50 [ 45.97327 3] bpf_xdp_link_release+0x3b8/0x3d0 [ 45.973834] bpf_link_free+0xd0/0x188 [ 45.974315 ] bpf_link_put+0x1d0/0x218 [ 45.974790] bpf_link_release+0x3c/0x58 [ 45.975291] __fput+0x20c/0x7e8 [ 45.975706] ____fput+0x24/0x30 [ 45.976117] 104/0x258 [ 45.976609] do_notify_resume+0x894/0xaf8 [ 45.977121] work_pending +0xc/0x328 [ 45.977575] [ 45.977775] La direcci\u00f3n del error pertenece a la p\u00e1gina: [ 45.978369] p\u00e1gina:fffffc00003e6600 refcount:0 mapcount:0 mapeo:00000000000000000 index:0x0 pfn:0x4f998 [ 45.97952 2] banderas: 0x7fffe0000000000(nodo=0| zona=0|lastcpupid=0x3ffff) [ 45.980349] raw: 07fffe0000000000 ffffc00003e6708 ffff0000dac3c010 0000000000000000 [ 45.981309] raw: 0000000000000000 000000000000000 00000000ffffffff 0000000000000000 [ 45.982259] p\u00e1gina volcada porque: kasan: mal acceso detectado [ 45.982948] [ 45.983153] Estado de la memoria alrededor de la direcci\u00f3n con errores : [ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.985533] >ffff00000f998080:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.986419] ^ [ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.988006] f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.988895] ===================================== ============================== [ 45.989773] Deshabilitar la depuraci\u00f3n de bloqueo debido a corrupci\u00f3n del kernel [ 45.990552] P\u00e1nico del kernel - no sincronizar: panic_on_warn establecido... [ 45.991166] CPU: 1 PID: 732 Comm: a.out Contaminado: GB 5.13.0+ #22 [ 45.991929] Nombre de hardware: linux,dummy-virt (DT) [ 45.992448] Seguimiento de llamadas: [ 45.992753] dump_backtrace+0x0/0x4c8 [ 45.993208] show_stack+0x30/0x40 [ 45.993627] dump_stack_lvl+0x120/0x18c [ 45.994113] dump_stack+0x1c/0x34 [ 45.994530 panic+0x3a4/0x7d 8 [ 45.994930] end_report+0x194/0x198 [ 45.995380] kasan_report+ 0x134/0x200 [ 45.995850] __asan_report_load8_noabort+0x2c/0x50 [ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0 [ 45.997007] bpf_link_free+0xd0/0x188 [ 45.99747 4] bpf_link_put+0x1d0/0x218 [ 45.997942] bpf_link_release+0x3c/0x58 [ 45.998429] __fput+0x20c/ 0x7e8 [ 45.998833] ____fput+0x24/0x30 [ 45.999247] task_work_run+0x104/0x258 [ 45.999731] do_notify_resume+0x894/0xaf8 [ 46.000236] work_pending ---truncado---"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix tail_call_reachable rejection for interpreter when jit failed\n\nDuring testing of f263a81451c1 (\"bpf: Track subprog poke descriptors correctly\nand fix use-after-free\") under various failure conditions, for example, when\njit_subprogs() fails and tries to clean up the program to be run under the\ninterpreter, we ran into the following freeze:\n\n [...]\n #127/8 tailcall_bpf2bpf_3:FAIL\n [...]\n [ 92.041251] BUG: KASAN: slab-out-of-bounds in ___bpf_prog_run+0x1b9d/0x2e20\n [ 92.042408] Read of size 8 at addr ffff88800da67f68 by task test_progs/682\n [ 92.043707]\n [ 92.044030] CPU: 1 PID: 682 Comm: test_progs Tainted: G O 5.13.0-53301-ge6c08cb33a30-dirty #87\n [ 92.045542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014\n [ 92.046785] Call Trace:\n [ 92.047171] ? __bpf_prog_run_args64+0xc0/0xc0\n [ 92.047773] ? __bpf_prog_run_args32+0x8b/0xb0\n [ 92.048389] ? __bpf_prog_run_args64+0xc0/0xc0\n [ 92.049019] ? ktime_get+0x117/0x130\n [...] // few hundred [similar] lines more\n [ 92.659025] ? ktime_get+0x117/0x130\n [ 92.659845] ? __bpf_prog_run_args64+0xc0/0xc0\n [ 92.660738] ? __bpf_prog_run_args32+0x8b/0xb0\n [ 92.661528] ? __bpf_prog_run_args64+0xc0/0xc0\n [ 92.662378] ? print_usage_bug+0x50/0x50\n [ 92.663221] ? print_usage_bug+0x50/0x50\n [ 92.664077] ? bpf_ksym_find+0x9c/0xe0\n [ 92.664887] ? ktime_get+0x117/0x130\n [ 92.665624] ? kernel_text_address+0xf5/0x100\n [ 92.666529] ? __kernel_text_address+0xe/0x30\n [ 92.667725] ? unwind_get_return_address+0x2f/0x50\n [ 92.668854] ? ___bpf_prog_run+0x15d4/0x2e20\n [ 92.670185] ? ktime_get+0x117/0x130\n [ 92.671130] ? __bpf_prog_run_args64+0xc0/0xc0\n [ 92.672020] ? __bpf_prog_run_args32+0x8b/0xb0\n [ 92.672860] ? __bpf_prog_run_args64+0xc0/0xc0\n [ 92.675159] ? ktime_get+0x117/0x130\n [ 92.677074] ? lock_is_held_type+0xd5/0x130\n [ 92.678662] ? ___bpf_prog_run+0x15d4/0x2e20\n [ 92.680046] ? ktime_get+0x117/0x130\n [ 92.681285] ? __bpf_prog_run32+0x6b/0x90\n [ 92.682601] ? __bpf_prog_run64+0x90/0x90\n [ 92.683636] ? lock_downgrade+0x370/0x370\n [ 92.684647] ? mark_held_locks+0x44/0x90\n [ 92.685652] ? ktime_get+0x117/0x130\n [ 92.686752] ? lockdep_hardirqs_on+0x79/0x100\n [ 92.688004] ? ktime_get+0x117/0x130\n [ 92.688573] ? __cant_migrate+0x2b/0x80\n [ 92.689192] ? bpf_test_run+0x2f4/0x510\n [ 92.689869] ? bpf_test_timer_continue+0x1c0/0x1c0\n [ 92.690856] ? rcu_read_lock_bh_held+0x90/0x90\n [ 92.691506] ? __kasan_slab_alloc+0x61/0x80\n [ 92.692128] ? eth_type_trans+0x128/0x240\n [ 92.692737] ? __build_skb+0x46/0x50\n [ 92.693252] ? bpf_prog_test_run_skb+0x65e/0xc50\n [ 92.693954] ? bpf_prog_test_run_raw_tp+0x2d0/0x2d0\n [ 92.694639] ? __fget_light+0xa1/0x100\n [ 92.695162] ? bpf_prog_inc+0x23/0x30\n [ 92.695685] ? __sys_bpf+0xb40/0x2c80\n [ 92.696324] ? bpf_link_get_from_fd+0x90/0x90\n [ 92.697150] ? mark_held_locks+0x24/0x90\n [ 92.698007] ? lockdep_hardirqs_on_prepare+0x124/0x220\n [ 92.699045] ? finish_task_switch+0xe6/0x370\n [ 92.700072] ? lockdep_hardirqs_on+0x79/0x100\n [ 92.701233] ? finish_task_switch+0x11d/0x370\n [ 92.702264] ? __switch_to+0x2c0/0x740\n [ 92.703148] ? mark_held_locks+0x24/0x90\n [ 92.704155] ? __x64_sys_bpf+0x45/0x50\n [ 92.705146] ? do_syscall_64+0x35/0x80\n [ 92.706953] ? entry_SYSCALL_64_after_hwframe+0x44/0xae\n [...]\n\nTurns out that the program rejection from e411901c0b77 (\"bpf: allow for tailcalls\nin BPF subprograms for x64 JIT\") is buggy since env->prog->aux->tail_call_reachable\nis never true. Commit ebf7d1f508a7 (\"bpf, x64: rework pro/epilogue and tailcall\nhandling in JIT\") added a tracker into check_max_stack_depth() which propagates\nthe tail_call_reachable condition throughout the subprograms. This info is then\nassigned to the subprogram's \n---truncated---"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: bpf: corrige el rechazo de tail_call_reachable para el int\u00e9rprete cuando falla jit. Durante las pruebas de f263a81451c1 (\"bpf: rastrea correctamente los descriptores de inserci\u00f3n del subprog y corrige el use after free\") bajo varias condiciones de fallo, por Por ejemplo, cuando jit_subprogs() falla e intenta limpiar el programa que se ejecutar\u00e1 bajo el int\u00e9rprete, nos encontramos con el siguiente congelamiento: [...] #127/8 tailcall_bpf2bpf_3:FAIL [...] [ 92.041251] ERROR: KASAN: slab fuera de los l\u00edmites en ___bpf_prog_run+0x1b9d/0x2e20 [92.042408] Lectura de tama\u00f1o 8 en la direcci\u00f3n ffff88800da67f68 por tarea test_progs/682 [92.043707] [92.044030] CPU: 1 PID: 682 Comm: _progs Contaminado: GO 5.13. 0-53301-ge6c08cb33a30-dirty #87 [92.045542] Nombre del hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 01/04/2014 [92.046785] Seguimiento de llamadas: [92.047171] ? __bpf_prog_run_args64+0xc0/0xc0 [92.047773]? __bpf_prog_run_args32+0x8b/0xb0 [92.048389]? __bpf_prog_run_args64+0xc0/0xc0 [92.049019]? ktime_get+0x117/0x130 [...] // \u00bfunos cientos de l\u00edneas [similares] m\u00e1s [92.659025]? ktime_get+0x117/0x130 [92.659845]? __bpf_prog_run_args64+0xc0/0xc0 [92.660738]? __bpf_prog_run_args32+0x8b/0xb0 [92.661528]? __bpf_prog_run_args64+0xc0/0xc0 [92.662378]? print_usage_bug+0x50/0x50 [92.663221]? print_usage_bug+0x50/0x50 [92.664077]? bpf_ksym_find+0x9c/0xe0 [92.664887]? ktime_get+0x117/0x130 [92.665624]? kernel_text_address+0xf5/0x100 [92.666529]? __kernel_text_address+0xe/0x30 [ 92.667725] ? unwind_get_return_address+0x2f/0x50 [92.668854]? ___bpf_prog_run+0x15d4/0x2e20 [ 92.670185] ? ktime_get+0x117/0x130 [92.671130]? __bpf_prog_run_args64+0xc0/0xc0 [92.672020]? __bpf_prog_run_args32+0x8b/0xb0 [92.672860]? __bpf_prog_run_args64+0xc0/0xc0 [92.675159]? ktime_get+0x117/0x130 [92.677074]? lock_is_held_type+0xd5/0x130 [92.678662]? ___bpf_prog_run+0x15d4/0x2e20 [ 92.680046] ? ktime_get+0x117/0x130 [92.681285]? __bpf_prog_run32+0x6b/0x90 [92.682601]? __bpf_prog_run64+0x90/0x90 [92.683636]? lock_downgrade+0x370/0x370 [92.684647]? mark_held_locks+0x44/0x90 [92.685652]? ktime_get+0x117/0x130 [92.686752]? lockdep_hardirqs_on+0x79/0x100 [92.688004]? ktime_get+0x117/0x130 [92.688573]? __cant_migrate+0x2b/0x80 [ 92.689192] ? bpf_test_run+0x2f4/0x510 [92.689869]? bpf_test_timer_continue+0x1c0/0x1c0 [92.690856]? rcu_read_lock_bh_held+0x90/0x90 [92.691506]? __kasan_slab_alloc+0x61/0x80 [92.692128]? eth_type_trans+0x128/0x240 [92.692737]? __build_skb+0x46/0x50 [92.693252]? bpf_prog_test_run_skb+0x65e/0xc50 [92.693954]? bpf_prog_test_run_raw_tp+0x2d0/0x2d0 [92.694639]? __fget_light+0xa1/0x100 [ 92.695162] ? bpf_prog_inc+0x23/0x30 [92.695685]? __sys_bpf+0xb40/0x2c80 [92.696324]? bpf_link_get_from_fd+0x90/0x90 [92.697150]? mark_held_locks+0x24/0x90 [92.698007]? lockdep_hardirqs_on_prepare+0x124/0x220 [92.699045]? finish_task_switch+0xe6/0x370 [92.700072]? lockdep_hardirqs_on+0x79/0x100 [92.701233]? finish_task_switch+0x11d/0x370 [92.702264]? __switch_to+0x2c0/0x740 [ 92.703148] ? mark_held_locks+0x24/0x90 [92.704155]? __x64_sys_bpf+0x45/0x50 [92.705146]? do_syscall_64+0x35/0x80 [92.706953]? Entry_SYSCALL_64_after_hwframe+0x44/0xae [...] Resulta que el rechazo del programa de e411901c0b77 (\"bpf: permitir tailcalls en subprogramas BPF para x64 JIT\") tiene errores ya que env->prog->aux->tail_call_reachable nunca es cierto. La confirmaci\u00f3n ebf7d1f508a7 (\"bpf, x64: reelaboraci\u00f3n de pro/ep\u00edlogo y manejo de tailcall en JIT\") agreg\u00f3 un rastreador en check_max_stack_ Depth() que propaga la condici\u00f3n tail_call_reachable a trav\u00e9s de los subprogramas. Esta informaci\u00f3n luego se asigna al ---truncado--- del subprograma."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nigb: Fix use-after-free error during reset\n\nCleans the next descriptor to watch (next_to_watch) when cleaning the\nTX ring.\n\nFailure to do so can cause invalid memory accesses. If igb_poll() runs\nwhile the controller is reset this can lead to the driver try to free\na skb that was already freed.\n\n(The crash is harder to reproduce with the igb driver, but the same\npotential problem exists as the code is identical to igc)"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: corrige el error de use after free durante el reinicio. Limpia el siguiente descriptor a observar (next_to_watch) al limpiar el anillo TX. De lo contrario, se pueden producir accesos a la memoria no v\u00e1lidos. Si igb_poll() se ejecuta mientras se reinicia el controlador, esto puede hacer que el controlador intente liberar un skb que ya estaba liberado. (El fallo es m\u00e1s dif\u00edcil de reproducir con el controlador igb, pero existe el mismo problema potencial ya que el c\u00f3digo es id\u00e9ntico al de igc)"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nigc: Fix use-after-free error during reset\n\nCleans the next descriptor to watch (next_to_watch) when cleaning the\nTX ring.\n\nFailure to do so can cause invalid memory accesses. If igc_poll() runs\nwhile the controller is being reset this can lead to the driver try to\nfree a skb that was already freed.\n\nLog message:\n\n [ 101.525242] refcount_t: underflow; use-after-free.\n [ 101.525251] WARNING: CPU: 1 PID: 646 at lib/refcount.c:28 refcount_warn_saturate+0xab/0xf0\n [ 101.525259] Modules linked in: sch_etf(E) sch_mqprio(E) rfkill(E) intel_rapl_msr(E) intel_rapl_common(E)\n x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E)\n ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) snd_hda_codec_hdmi(E)\n rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E)\n soundwire_generic_allocation(E) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E)\n iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E)\n soundwire_bus(E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E)\n autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E)\n i915(E) ahci(E) libahci(E) ehci_pci(E) igb(E) xhci_pci(E) ehci_hcd(E)\n [ 101.525303] drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E)\n e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E)\n usbcore(E) drm(E) button(E) video(E)\n [ 101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Tainted: G E 5.10.30-rt37-tsn1-rt-ipipe #ipipe\n [ 101.525320] Hardware name: SIEMENS AG SIMATIC IPC427D/A5E31233588, BIOS V17.02.09 03/31/2017\n [ 101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0\n [ 101.525325] Code: 05 31 48 44 01 01 e8 f0 c6 42 00 0f 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48\n 44 01 01 e8 d1 c6 42 00 <0f> 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff ff 48 c7 c7 d0 a8 f3\n [ 101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286\n [ 101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001\n [ 101.525330] RDX: 0000000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff\n [ 101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50\n [ 101.525333] R10: ffffffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00\n [ 101.525335] R13: ffff98fd6b0b1000 R14: 0000000000000039 R15: ffff98fd6be35c40\n [ 101.525337] FS: 0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000\n [ 101.525339] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ 101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0\n [ 101.525343] Call Trace:\n [ 101.525346] sock_wfree+0x9c/0xa0\n [ 101.525353] unix_destruct_scm+0x7b/0xa0\n [ 101.525358] skb_release_head_state+0x40/0x90\n [ 101.525362] skb_release_all+0xe/0x30\n [ 101.525364] napi_consume_skb+0x57/0x160\n [ 101.525367] igc_poll+0xb7/0xc80 [igc]\n [ 101.525376] ? sched_clock+0x5/0x10\n [ 101.525381] ? sched_clock_cpu+0xe/0x100\n [ 101.525385] net_rx_action+0x14c/0x410\n [ 101.525388] __do_softirq+0xe9/0x2f4\n [ 101.525391] __local_bh_enable_ip+0xe3/0x110\n [ 101.525395] ? irq_finalize_oneshot.part.47+0xe0/0xe0\n [ 101.525398] irq_forced_thread_fn+0x6a/0x80\n [ 101.525401] irq_thread+0xe8/0x180\n [ 101.525403] ? wake_threads_waitq+0x30/0x30\n [ 101.525406] ? irq_thread_check_affinity+0xd0/0xd0\n [ 101.525408] kthread+0x183/0x1a0\n [ 101.525412] ? kthread_park+0x80/0x80\n [ 101.525415] ret_from_fork+0x22/0x30"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igc: corrige el error de use after free durante el reinicio. Limpia el siguiente descriptor a observar (next_to_watch) al limpiar el anillo TX. De lo contrario, se pueden producir accesos a la memoria no v\u00e1lidos. Si igc_poll() se ejecuta mientras se reinicia el controlador, esto puede hacer que el controlador intente liberar un skb que ya estaba liberado. Mensaje de registro: [101.525242] refcount_t: desbordamiento insuficiente; use after free. [101.525251] ADVERTENCIA: CPU: 1 PID: 646 AT LIB/REFCOUNT.C: 28 RefCount_warn_saturate+0xab/0xf0 [101.525259] M\u00f3dulos vinculados en: Sch_etf (E) Sch_Mqprio (E) RFKILL (E) INTEL_RAPL_MSR (E) INTER ) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E) ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd (E) cryptd(E) pegamento_helper(E) snd_hda_codec_hdmi(E) rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E) soundwire_generic_allocation(E) ) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E) iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E) soundwire_bus (E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) text4(E ) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) i915(E) ahci(E) libahci(E) ehci_pci(E) igb (E) xhci_pci(E) ehci_hcd(E) [ 101.525303] drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E) e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E) usbcore(E) drm(E) button( E) video(E) [ 101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Contaminado: GE 5.10.30-rt37-tsn1-rt-ipipe #ipipe [ 101.525320] Nombre de hardware: SIEMENS AG SIMATIC IPC427D /A5E31233588, BIOS V17.02.09 31/03/2017 [ 101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0 [ 101.525325] C\u00f3digo: 05 31 48 44 01 01 e8 f0 c6 42 00 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48 44 01 01 e8 d1 c6 42 00 <0f> 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff 48 c7 c7 d0 a8 f3 [ 101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286 [ 101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001 [ 101.525330] RDX: 000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff [ 101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50 [ 101.525333] fffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00 [ 101.525335] R13: ffff98fd6b0b1000 R14: 00000000000000039 R15: ffff98fd6be35c40 [ 101.525337] FS: 0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000 [ 101.525339] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0 [ 101.525343] Seguimiento de llamadas: [ 101.525346] sock_wfree+0x9c/0xa0 [ 101.52 5353] unix_destruct_scm+0x7b/0xa0 [ 101.525358] skb_release_head_state+0x40/0x90 [ 101.525362] skb_release_all+0xe/0x30 [ 101.525364] napi_consume_skb+0x57/0x160 [ 101.525367] igc_poll+0xb7/0xc80 [igc] [ 101.525376] ? sched_clock+0x5/0x10 [101.525381]? sched_clock_cpu+0xe/0x100 [ 101.525385] net_rx_action+0x14c/0x410 [ 101.525388] __do_softirq+0xe9/0x2f4 [ 101.525391] __local_bh_enable_ip+0xe3/0x110 [ 5395] ? irq_finalize_oneshot.part.47+0xe0/0xe0 [ 101.525398] irq_forced_thread_fn+0x6a/0x80 [ 101.525401] irq_thread+0xe8/0x180 [ 101.525403] ? wake_threads_waitq+0x30/0x30 [101.525406]? irq_thread_check_affinity+0xd0/0xd0 [ 101.525408] kthread+0x183/0x1a0 [ 101.525412] ? kthread_park+0x80/0x80 [ 101.525415] ret_from_fork+0x22/0x30"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Track subprog poke descriptors correctly and fix use-after-free\n\nSubprograms are calling map_poke_track(), but on program release there is no\nhook to call map_poke_untrack(). However, on program release, the aux memory\n(and poke descriptor table) is freed even though we still have a reference to\nit in the element list of the map aux data. When we run map_poke_run(), we then\nend up accessing free'd memory, triggering KASAN in prog_array_map_poke_run():\n\n [...]\n [ 402.824689] BUG: KASAN: use-after-free in prog_array_map_poke_run+0xc2/0x34e\n [ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337\n [ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399\n [ 402.824715] Call Trace:\n [ 402.824719] dump_stack+0x93/0xc2\n [ 402.824727] print_address_description.constprop.0+0x1a/0x140\n [ 402.824736] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824740] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824744] kasan_report.cold+0x7c/0xd8\n [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824757] prog_array_map_poke_run+0xc2/0x34e\n [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0\n [...]\n\nThe elements concerned are walked as follows:\n\n for (i = 0; i < elem->aux->size_poke_tab; i++) {\n poke = &elem->aux->poke_tab[i];\n [...]\n\nThe access to size_poke_tab is a 4 byte read, verified by checking offsets\nin the KASAN dump:\n\n [ 402.825004] The buggy address belongs to the object at ffff8881905a7800\n which belongs to the cache kmalloc-1k of size 1024\n [ 402.825008] The buggy address is located 320 bytes inside of\n 1024-byte region [ffff8881905a7800, ffff8881905a7c00)\n\nThe pahole output of bpf_prog_aux:\n\n struct bpf_prog_aux {\n [...]\n /* --- cacheline 5 boundary (320 bytes) --- */\n u32 size_poke_tab; /* 320 4 */\n [...]\n\nIn general, subprograms do not necessarily manage their own data structures.\nFor example, BTF func_info and linfo are just pointers to the main program\nstructure. This allows reference counting and cleanup to be done on the latter\nwhich simplifies their management a bit. The aux->poke_tab struct, however,\ndid not follow this logic. The initial proposed fix for this use-after-free\nbug further embedded poke data tracking into the subprogram with proper\nreference counting. However, Daniel and Alexei questioned why we were treating\nthese objects special; I agree, its unnecessary. The fix here removes the per\nsubprogram poke table allocation and map tracking and instead simply points\nthe aux->poke_tab pointer at the main programs poke table. This way, map\ntracking is simplified to the main program and we do not need to manage them\nper subprogram.\n\nThis also means, bpf_prog_free_deferred(), which unwinds the program reference\ncounting and kfrees objects, needs to ensure that we don't try to double free\nthe poke_tab when free'ing the subprog structures. This is easily solved by\nNULL'ing the poke_tab pointer. The second detail is to ensure that per\nsubprogram JIT logic only does fixups on poke_tab[] entries it owns. To do\nthis, we add a pointer in the poke structure to point at the subprogram value\nso JITs can easily check while walking the poke_tab structure if the current\nentry belongs to the current program. The aux pointer is stable and therefore\nsuitable for such comparison. On the jit_subprogs() error path, we omit\ncleaning up the poke->aux field because these are only ever referenced from\nthe JIT side, but on error we will never make it to the JIT, so its fine to\nleave them dangling. Removing these pointers would complicate the error path\nfor no reason. However, we do need to untrack all poke descriptors from the\nmain program as otherwise they could race with the freeing of JIT memory from\nthe subprograms. Lastly, a748c6975dea3 (\"bpf: propagate poke des\n---truncated---"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: realiza un seguimiento correcto de los descriptores de poke del subprog y corrige el use-after-free. Los subprogramas llaman a map_poke_track(), pero en el lanzamiento del programa no hay ning\u00fan enlace para llamar a map_poke_untrack(). Sin embargo, al lanzar el programa, la memoria auxiliar (y la tabla de descriptores de inserci\u00f3n) se liberan aunque todav\u00eda tengamos una referencia a ella en la lista de elementos de los datos auxiliares del mapa. Cuando ejecutamos map_poke_run(), terminamos accediendo a la memoria liberada, lo que activa KASAN en prog_array_map_poke_run(): [...] [402.824689] ERROR: KASAN: use-after-free en prog_array_map_poke_run+0xc2/0x34e [402.824698] Lectura del tama\u00f1o 4 en la direcci\u00f3n ffff8881905a7940 mediante la tarea hubble-fgs/4337 [402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Contaminado: GI 5.12.0+ #399 [402.824715] Seguimiento de llamadas: [402.824719] x93/ 0xc2 [402.824727] print_address_description.constprop.0+0x1a/0x140 [402.824736]? prog_array_map_poke_run+0xc2/0x34e [402.824740]? prog_array_map_poke_run+0xc2/0x34e [ 402.824744] kasan_report.cold+0x7c/0xd8 [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824757] prog_array_map_poke_run+0xc2/0x34e [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0 [...] Los elementos en cuesti\u00f3n se recorren de la siguiente manera: for (i = 0; i < elem-> aux->tama\u00f1o_poke_tab; i++) { empujar = &elem->aux->poke_tab[i]; [...] El acceso a size_poke_tab es una lectura de 4 bytes, verificada verificando las compensaciones en el volcado de KASAN: [402.825004] La direcci\u00f3n con errores pertenece al objeto en ffff8881905a7800 que pertenece al cach\u00e9 kmalloc-1k de tama\u00f1o 1024 [402.825008] La direcci\u00f3n con errores se encuentra a 320 bytes dentro de una regi\u00f3n de 1024 bytes [ffff8881905a7800, ffff8881905a7c00) La salida de error de bpf_prog_aux: struct bpf_prog_aux { [...] /* --- l\u00edmite de cacheline 5 (320 bytes) --- */ u32 tama\u00f1o_poke_tab; /* 320 4 */ [...] En general, los subprogramas no necesariamente gestionan sus propias estructuras de datos. Por ejemplo, BTF func_info y linfo son s\u00f3lo punteros a la estructura principal del programa. Esto permite realizar un recuento de referencias y una sanitizaci\u00f3n de estos \u00faltimos, lo que simplifica un poco su gesti\u00f3n. La estructura aux->poke_tab, sin embargo, no sigui\u00f3 esta l\u00f3gica. La soluci\u00f3n inicial propuesta para este error de use-after-free incorpor\u00f3 a\u00fan m\u00e1s el seguimiento de datos de inserci\u00f3n en el subprograma con un recuento de referencias adecuado. Sin embargo, Daniel y Alexei se preguntaron por qu\u00e9 trat\u00e1bamos a estos objetos de manera especial; Estoy de acuerdo, es innecesario. La soluci\u00f3n aqu\u00ed elimina la asignaci\u00f3n de la tabla de poke por subprograma y el seguimiento del mapa y, en su lugar, simplemente apunta el puntero aux->poke_tab a la tabla de poke del programa principal. De esta manera, el seguimiento de mapas se simplifica al programa principal y no necesitamos gestionarlos por subprograma. Esto tambi\u00e9n significa que bpf_prog_free_deferred(), que desenrolla el recuento de referencias del programa y libera objetos, debe garantizar que no intentemos liberar dos veces el poke_tab al liberar las estructuras de subprog. Esto se resuelve f\u00e1cilmente haciendo NULL en el puntero poke_tab. El segundo detalle es garantizar que la l\u00f3gica JIT por subprograma solo realice correcciones en las entradas poke_tab[] que posee. Para hacer esto, agregamos un puntero en la estructura poke para se\u00f1alar el valor del subprograma para que los JIT puedan verificar f\u00e1cilmente mientras recorren la estructura poke_tab si la entrada actual pertenece al programa actual. El puntero auxiliar es estable y, por tanto, adecuado para dicha comparaci\u00f3n. ---truncado---"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix tcp_init_transfer() to not reset icsk_ca_initialized\n\nThis commit fixes a bug (found by syzkaller) that could cause spurious\ndouble-initializations for congestion control modules, which could cause\nmemory leaks or other problems for congestion control modules (like CDG)\nthat allocate memory in their init functions.\n\nThe buggy scenario constructed by syzkaller was something like:\n\n(1) create a TCP socket\n(2) initiate a TFO connect via sendto()\n(3) while socket is in TCP_SYN_SENT, call setsockopt(TCP_CONGESTION),\n which calls:\n tcp_set_congestion_control() ->\n tcp_reinit_congestion_control() ->\n tcp_init_congestion_control()\n(4) receive ACK, connection is established, call tcp_init_transfer(),\n set icsk_ca_initialized=0 (without first calling cc->release()),\n call tcp_init_congestion_control() again.\n\nNote that in this sequence tcp_init_congestion_control() is called\ntwice without a cc->release() call in between. Thus, for CC modules\nthat allocate memory in their init() function, e.g, CDG, a memory leak\nmay occur. The syzkaller tool managed to find a reproducer that\ntriggered such a leak in CDG.\n\nThe bug was introduced when that commit 8919a9b31eb4 (\"tcp: Only init\ncongestion control if not initialized already\")\nintroduced icsk_ca_initialized and set icsk_ca_initialized to 0 in\ntcp_init_transfer(), missing the possibility for a sequence like the\none above, where a process could call setsockopt(TCP_CONGESTION) in\nstate TCP_SYN_SENT (i.e. after the connect() or TFO open sendmsg()),\nwhich would call tcp_init_congestion_control(). It did not intend to\nreset any initialization that the user had already explicitly made;\nit just missed the possibility of that particular sequence (which\nsyzkaller managed to find)."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: corrige tcp_init_transfer() para no restablecer icsk_ca_initialized Esta confirmaci\u00f3n corrige un error (encontrado por syzkaller) que podr\u00eda causar dobles inicializaciones falsas para los m\u00f3dulos de control de congesti\u00f3n, lo que podr\u00eda causar p\u00e9rdidas de memoria o Otros problemas para los m\u00f3dulos de control de congesti\u00f3n (como CDG) que asignan memoria en sus funciones de inicio. El escenario con errores construido por syzkaller era algo as\u00ed como: (1) crear un socket TCP (2) iniciar una conexi\u00f3n TFO a trav\u00e9s de sendto() (3) mientras el socket est\u00e1 en TCP_SYN_SENT, llamar a setsockopt(TCP_CONGESTION), que llama a: tcp_set_congestion_control() - > tcp_reinit_congestion_control() -> tcp_init_congestion_control() (4) recibe ACK, se establece la conexi\u00f3n, llama a tcp_init_transfer(), establece icsk_ca_initialized=0 (sin llamar primero a cc->release()), llama a tcp_init_congestion_control() nuevamente. Tenga en cuenta que en esta secuencia tcp_init_congestion_control() se llama dos veces sin una llamada cc->release() en el medio. Por lo tanto, para los m\u00f3dulos CC que asignan memoria en su funci\u00f3n init(), por ejemplo, CDG, puede ocurrir una p\u00e9rdida de memoria. La herramienta syzkaller logr\u00f3 encontrar un reproductor que desencaden\u00f3 dicha filtraci\u00f3n en CDG. El error se introdujo cuando la confirmaci\u00f3n 8919a9b31eb4 (\"tcp: solo inicia el control de congesti\u00f3n si a\u00fan no est\u00e1 inicializado\") introdujo icsk_ca_initialized y estableci\u00f3 icsk_ca_initialized en 0 en tcp_init_transfer(), perdiendo la posibilidad de una secuencia como la anterior, donde un proceso podr\u00eda llamar setsockopt(TCP_CONGESTION) en el estado TCP_SYN_SENT (es decir, despu\u00e9s de connect() o TFO open sendmsg()), que llamar\u00eda a tcp_init_congestion_control(). No ten\u00eda la intenci\u00f3n de restablecer ninguna inicializaci\u00f3n que el usuario ya hubiera realizado expl\u00edcitamente; simplemente perdi\u00f3 la posibilidad de esa secuencia particular (que Syzkaller logr\u00f3 encontrar)."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf/sync_file: Don't leak fences on merge failure\n\nEach add_fence() call does a dma_fence_get() on the relevant fence. In\nthe error path, we weren't calling dma_fence_put() so all those fences\ngot leaked. Also, in the krealloc_array failure case, we weren't\nfreeing the fences array. Instead, ensure that i and fences are always\nzero-initialized and dma_fence_put() all the fences and kfree(fences) on\nevery error path."
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf/sync_file: no filtrar barreras en caso de falla de fusi\u00f3n. Cada llamada a add_fence() realiza un dma_fence_get() en la barrera relevante. En la ruta del error, no est\u00e1bamos llamando a dma_fence_put() por lo que se filtraron todas esas barreras. Adem\u00e1s, en el caso de falla de krealloc_array, no est\u00e1bamos liberando la matriz de vallas. En su lugar, aseg\u00farese de que i y las vallas est\u00e9n siempre inicializadas en cero y dma_fence_put() todas las vallas y kfree(fences) en cada ruta de error."
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
@ -8,6 +8,10 @@
|
||||
{
|
||||
"lang": "en",
|
||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fddi: fix UAF in fza_probe\n\nfp is netdev private data and it cannot be\nused after free_netdev() call. Using fp after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() after error message.\n\nTURBOchannel adapter\")"
|
||||
},
|
||||
{
|
||||
"lang": "es",
|
||||
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fddi: corrige UAF en fza_probe fp son datos privados de netdev y no se pueden usar despu\u00e9s de la llamada a free_netdev(). Usar fp despu\u00e9s de free_netdev() puede causar un error UAF. Solucionadlo moviendo free_netdev() despu\u00e9s del mensaje de error. Adaptador de canal TURBO\")"
|
||||
}
|
||||
],
|
||||
"metrics": {},
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user