Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2022-49513 (GCVE-0-2022-49513)
Vulnerability from cvelistv5 – Published: 2025-02-26 02:13 – Updated: 2026-05-11 19:01| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
c4435630361d9bebf7154a0c842dc1fb7ae39c99 , < a1964688582d26af1328e19b658933659fb54337
(git)
Affected: c4435630361d9bebf7154a0c842dc1fb7ae39c99 , < 1e32083f327184b6226ce320ef30085ce785ea4e (git) Affected: c4435630361d9bebf7154a0c842dc1fb7ae39c99 , < a85ee6401a47ae3fc64ba506cacb3e7873823c65 (git) |
guessed | |
| Linux | Linux |
Affected:
4.6
Unaffected: 0 , < 4.6 (semver) Unaffected: 5.15.91 , ≤ 5.15.* (semver) Unaffected: 5.18.3 , ≤ 5.18.* (semver) Unaffected: 5.19 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/cpufreq/cpufreq_governor.c",
"drivers/cpufreq/cpufreq_governor.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "a1964688582d26af1328e19b658933659fb54337",
"status": "affected",
"version": "c4435630361d9bebf7154a0c842dc1fb7ae39c99",
"versionType": "git"
},
{
"lessThan": "1e32083f327184b6226ce320ef30085ce785ea4e",
"status": "affected",
"version": "c4435630361d9bebf7154a0c842dc1fb7ae39c99",
"versionType": "git"
},
{
"lessThan": "a85ee6401a47ae3fc64ba506cacb3e7873823c65",
"status": "affected",
"version": "c4435630361d9bebf7154a0c842dc1fb7ae39c99",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/cpufreq/cpufreq_governor.c",
"drivers/cpufreq/cpufreq_governor.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.6"
},
{
"lessThan": "4.6",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.91",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.18.*",
"status": "unaffected",
"version": "5.18.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.91",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.18.3",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.19",
"versionStartIncluding": "4.6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: governor: Use kobject release() method to free dbs_data\n\nThe struct dbs_data embeds a struct gov_attr_set and\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\na release() method and we can\u0027t use kfree() to free it directly,\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\nthe kobject::release() method. This fixes the calltrace like below:\n\n ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\n WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n Modules linked in:\n CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\n Hardware name: Marvell OcteonTX CN96XX board (DT)\n pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : debug_print_object+0xb8/0x100\n lr : debug_print_object+0xb8/0x100\n sp : ffff80001dfcf9a0\n x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\n x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\n x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\n x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\n x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\n x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\n x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\n x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\n x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\n Call trace:\n debug_print_object+0xb8/0x100\n __debug_check_no_obj_freed+0x1d0/0x25c\n debug_check_no_obj_freed+0x24/0xa0\n kfree+0x11c/0x440\n cpufreq_dbs_governor_exit+0xa8/0xac\n cpufreq_exit_governor+0x44/0x90\n cpufreq_set_policy+0x29c/0x570\n store_scaling_governor+0x110/0x154\n store+0xb0/0xe0\n sysfs_kf_write+0x58/0x84\n kernfs_fop_write_iter+0x12c/0x1c0\n new_sync_write+0xf0/0x18c\n vfs_write+0x1cc/0x220\n ksys_write+0x74/0x100\n __arm64_sys_write+0x28/0x3c\n invoke_syscall.constprop.0+0x58/0xf0\n do_el0_svc+0x70/0x170\n el0_svc+0x54/0x190\n el0t_64_sync_handler+0xa4/0x130\n el0t_64_sync+0x1a0/0x1a4\n irq event stamp: 189006\n hardirqs last enabled at (189005): [\u003cffff8000080849d0\u003e] finish_task_switch.isra.0+0xe0/0x2c0\n hardirqs last disabled at (189006): [\u003cffff8000090667a4\u003e] el1_dbg+0x24/0xa0\n softirqs last enabled at (188966): [\u003cffff8000080106d0\u003e] __do_softirq+0x4b0/0x6a0\n softirqs last disabled at (188957): [\u003cffff80000804a618\u003e] __irq_exit_rcu+0x108/0x1a4\n\n[ rjw: Because can be freed by the gov_attr_set_put() in\n cpufreq_dbs_governor_exit() now, it is also necessary to put the\n invocation of the governor -\u003eexit() callback into the new\n cpufreq_dbs_data_release() function. ]"
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T19:01:22.530Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/a1964688582d26af1328e19b658933659fb54337"
},
{
"url": "https://git.kernel.org/stable/c/1e32083f327184b6226ce320ef30085ce785ea4e"
},
{
"url": "https://git.kernel.org/stable/c/a85ee6401a47ae3fc64ba506cacb3e7873823c65"
}
],
"title": "cpufreq: governor: Use kobject release() method to free dbs_data",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2022-49513",
"datePublished": "2025-02-26T02:13:42.759Z",
"dateReserved": "2025-02-26T02:08:31.587Z",
"dateUpdated": "2026-05-11T19:01:22.530Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2022-49513",
"date": "2026-09-17",
"epss": "0.0026",
"percentile": "0.17979"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2022-49513\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-02-26T07:01:27.380\",\"lastModified\":\"2026-06-17T05:18:17.480\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\ncpufreq: governor: Use kobject release() method to free dbs_data\\n\\nThe struct dbs_data embeds a struct gov_attr_set and\\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\\na release() method and we can\u0027t use kfree() to free it directly,\\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\\nthe kobject::release() method. This fixes the calltrace like below:\\n\\n ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\\n WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\\n Modules linked in:\\n CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\\n Hardware name: Marvell OcteonTX CN96XX board (DT)\\n pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\\n pc : debug_print_object+0xb8/0x100\\n lr : debug_print_object+0xb8/0x100\\n sp : ffff80001dfcf9a0\\n x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\\n x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\\n x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\\n x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\\n x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\\n x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\\n x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\\n x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\\n x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\\n Call trace:\\n debug_print_object+0xb8/0x100\\n __debug_check_no_obj_freed+0x1d0/0x25c\\n debug_check_no_obj_freed+0x24/0xa0\\n kfree+0x11c/0x440\\n cpufreq_dbs_governor_exit+0xa8/0xac\\n cpufreq_exit_governor+0x44/0x90\\n cpufreq_set_policy+0x29c/0x570\\n store_scaling_governor+0x110/0x154\\n store+0xb0/0xe0\\n sysfs_kf_write+0x58/0x84\\n kernfs_fop_write_iter+0x12c/0x1c0\\n new_sync_write+0xf0/0x18c\\n vfs_write+0x1cc/0x220\\n ksys_write+0x74/0x100\\n __arm64_sys_write+0x28/0x3c\\n invoke_syscall.constprop.0+0x58/0xf0\\n do_el0_svc+0x70/0x170\\n el0_svc+0x54/0x190\\n el0t_64_sync_handler+0xa4/0x130\\n el0t_64_sync+0x1a0/0x1a4\\n irq event stamp: 189006\\n hardirqs last enabled at (189005): [\u003cffff8000080849d0\u003e] finish_task_switch.isra.0+0xe0/0x2c0\\n hardirqs last disabled at (189006): [\u003cffff8000090667a4\u003e] el1_dbg+0x24/0xa0\\n softirqs last enabled at (188966): [\u003cffff8000080106d0\u003e] __do_softirq+0x4b0/0x6a0\\n softirqs last disabled at (188957): [\u003cffff80000804a618\u003e] __irq_exit_rcu+0x108/0x1a4\\n\\n[ rjw: Because can be freed by the gov_attr_set_put() in\\n cpufreq_dbs_governor_exit() now, it is also necessary to put the\\n invocation of the governor -\u003eexit() callback into the new\\n cpufreq_dbs_data_release() function. ]\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: governor: Use el m\u00e9todo kobject release() para liberar dbs_data La estructura dbs_data incorpora una estructura gov_attr_set y la estructura gov_attr_set incorpora un kobject. Dado que cada kobject debe tener un m\u00e9todo release() y no podemos usar kfree() para liberarlo directamente, introduzca cpufreq_dbs_data_release() para liberar dbs_data a trav\u00e9s del m\u00e9todo kobject::release(). Esto corrige el seguimiento de llamadas como se muestra a continuaci\u00f3n: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4 [ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor -\u0026gt;exit() callback into the new cpufreq_dbs_data_release() function. ] \"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/cpufreq/cpufreq_governor.c\",\"drivers/cpufreq/cpufreq_governor.h\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"c4435630361d9bebf7154a0c842dc1fb7ae39c99\",\"lessThan\":\"a1964688582d26af1328e19b658933659fb54337\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c4435630361d9bebf7154a0c842dc1fb7ae39c99\",\"lessThan\":\"1e32083f327184b6226ce320ef30085ce785ea4e\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c4435630361d9bebf7154a0c842dc1fb7ae39c99\",\"lessThan\":\"a85ee6401a47ae3fc64ba506cacb3e7873823c65\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/cpufreq/cpufreq_governor.c\",\"drivers/cpufreq/cpufreq_governor.h\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"4.6\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"4.6\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.91\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.18.3\",\"lessThanOrEqual\":\"5.18.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.19\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.6\",\"versionEndExcluding\":\"5.15.91\",\"matchCriteriaId\":\"E971D8DD-B809-44DF-A31F-1A124020CE28\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"5.18.3\",\"matchCriteriaId\":\"98CD047E-3CA9-4A90-93B0-040784FAD016\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/1e32083f327184b6226ce320ef30085ce785ea4e\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/a1964688582d26af1328e19b658933659fb54337\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/a85ee6401a47ae3fc64ba506cacb3e7873823c65\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-29T21:09:51+00:00",
"cve": "CVE-2022-49513",
"id": "CVE-2022-49513",
"initial_release_date": "2022-01-01T00:00:00+00:00",
"product_status:fixed": "321",
"product_status:known_affected": "66",
"product_status:known_not_affected": "90",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: cpufreq: governor: Use kobject release() method to free dbs_data",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2022/cve-2022-49513.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-02T02:04:01Z",
"cve": "CVE-2022-49513",
"id": "CVE-2022-49513",
"initial_release_date": "2025-02-27T03:05:42Z",
"product_status:known_affected": "630",
"product_status:known_not_affected": "180",
"product_status:recommended": "73",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2022-49513",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2022-49513.json",
"version": "36"
}
}
}
CERTFR-2025-AVI-0336
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et une atteinte à la confidentialité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP5 | ||
| SUSE | N/A | SUSE Manager Proxy 4.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.3 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 LTSS | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP3 | ||
| SUSE | N/A | openSUSE Leap 15.4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP4 | ||
| SUSE | N/A | openSUSE Leap 15.5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 Business Critical Linux | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 12-SP5 | ||
| SUSE | N/A | SUSE Manager Retail Branch Server 4.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing LTSS 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP6 | ||
| SUSE | N/A | openSUSE Leap 15.6 | ||
| SUSE | N/A | SUSE Enterprise Storage 7.1 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP5 LTSS | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing ESPOS 15 SP5 | ||
| SUSE | N/A | SUSE Manager Server 4.2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 LTSS | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.1 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.4 | ||
| SUSE | N/A | openSUSE Leap 15.3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 LTSS Extended Security | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.5 |
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5 LTSS",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3 Business Critical Linux",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 12-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Retail Branch Server 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Enterprise Storage 7.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP5 LTSS",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing ESPOS 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3 LTSS",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5 LTSS Extended Security",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2017-5753",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-5753"
},
{
"name": "CVE-2020-27835",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27835"
},
{
"name": "CVE-2022-1016",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1016"
},
{
"name": "CVE-2022-1184",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1184"
},
{
"name": "CVE-2022-1048",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1048"
},
{
"name": "CVE-2022-26373",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26373"
},
{
"name": "CVE-2022-0168",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0168"
},
{
"name": "CVE-2022-3435",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3435"
},
{
"name": "CVE-2022-29901",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29901"
},
{
"name": "CVE-2022-29900",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29900"
},
{
"name": "CVE-2022-2977",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2977"
},
{
"name": "CVE-2022-3303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3303"
},
{
"name": "CVE-2023-0179",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0179"
},
{
"name": "CVE-2023-1652",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1652"
},
{
"name": "CVE-2023-28410",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28410"
},
{
"name": "CVE-2023-2162",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2162"
},
{
"name": "CVE-2023-3567",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3567"
},
{
"name": "CVE-2021-46925",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46925"
},
{
"name": "CVE-2024-26634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26634"
},
{
"name": "CVE-2021-47248",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47248"
},
{
"name": "CVE-2024-35910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35910"
},
{
"name": "CVE-2024-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38559"
},
{
"name": "CVE-2024-41005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41005"
},
{
"name": "CVE-2024-36968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36968"
},
{
"name": "CVE-2024-41090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41090"
},
{
"name": "CVE-2021-47517",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47517"
},
{
"name": "CVE-2022-49014",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49014"
},
{
"name": "CVE-2024-49935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49935"
},
{
"name": "CVE-2024-50269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50269"
},
{
"name": "CVE-2024-50290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50290"
},
{
"name": "CVE-2024-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53063"
},
{
"name": "CVE-2024-47678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47678"
},
{
"name": "CVE-2024-53140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53140"
},
{
"name": "CVE-2024-56642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56642"
},
{
"name": "CVE-2024-56651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56651"
},
{
"name": "CVE-2024-56600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56600"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2024-56633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56633"
},
{
"name": "CVE-2024-49940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49940"
},
{
"name": "CVE-2024-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53176"
},
{
"name": "CVE-2024-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53178"
},
{
"name": "CVE-2024-49571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49571"
},
{
"name": "CVE-2024-53680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53680"
},
{
"name": "CVE-2024-56640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56640"
},
{
"name": "CVE-2024-56770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56770"
},
{
"name": "CVE-2024-57900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57900"
},
{
"name": "CVE-2021-47633",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47633"
},
{
"name": "CVE-2021-47644",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47644"
},
{
"name": "CVE-2022-49076",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49076"
},
{
"name": "CVE-2022-49089",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49089"
},
{
"name": "CVE-2022-49134",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49134"
},
{
"name": "CVE-2022-49135",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49135"
},
{
"name": "CVE-2022-49151",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49151"
},
{
"name": "CVE-2022-49178",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49178"
},
{
"name": "CVE-2022-49182",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49182"
},
{
"name": "CVE-2022-49201",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49201"
},
{
"name": "CVE-2022-49247",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49247"
},
{
"name": "CVE-2022-49490",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49490"
},
{
"name": "CVE-2022-49626",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49626"
},
{
"name": "CVE-2022-49661",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49661"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2025-21802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21802"
},
{
"name": "CVE-2021-4453",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4453"
},
{
"name": "CVE-2021-47631",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47631"
},
{
"name": "CVE-2021-47632",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47632"
},
{
"name": "CVE-2021-47635",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47635"
},
{
"name": "CVE-2021-47636",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47636"
},
{
"name": "CVE-2021-47637",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47637"
},
{
"name": "CVE-2021-47638",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47638"
},
{
"name": "CVE-2021-47639",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47639"
},
{
"name": "CVE-2021-47641",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47641"
},
{
"name": "CVE-2021-47642",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47642"
},
{
"name": "CVE-2021-47643",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47643"
},
{
"name": "CVE-2021-47645",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47645"
},
{
"name": "CVE-2021-47646",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47646"
},
{
"name": "CVE-2021-47647",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47647"
},
{
"name": "CVE-2021-47648",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47648"
},
{
"name": "CVE-2021-47649",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47649"
},
{
"name": "CVE-2021-47650",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47650"
},
{
"name": "CVE-2021-47651",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47651"
},
{
"name": "CVE-2021-47652",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47652"
},
{
"name": "CVE-2021-47653",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47653"
},
{
"name": "CVE-2021-47654",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47654"
},
{
"name": "CVE-2021-47656",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47656"
},
{
"name": "CVE-2021-47657",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47657"
},
{
"name": "CVE-2021-47659",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47659"
},
{
"name": "CVE-2022-0995",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0995"
},
{
"name": "CVE-2022-49044",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49044"
},
{
"name": "CVE-2022-49050",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49050"
},
{
"name": "CVE-2022-49051",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49051"
},
{
"name": "CVE-2022-49054",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49054"
},
{
"name": "CVE-2022-49055",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49055"
},
{
"name": "CVE-2022-49058",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49058"
},
{
"name": "CVE-2022-49059",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49059"
},
{
"name": "CVE-2022-49060",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49060"
},
{
"name": "CVE-2022-49061",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49061"
},
{
"name": "CVE-2022-49063",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49063"
},
{
"name": "CVE-2022-49065",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49065"
},
{
"name": "CVE-2022-49066",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49066"
},
{
"name": "CVE-2022-49073",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49073"
},
{
"name": "CVE-2022-49074",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49074"
},
{
"name": "CVE-2022-49078",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49078"
},
{
"name": "CVE-2022-49082",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49082"
},
{
"name": "CVE-2022-49083",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49083"
},
{
"name": "CVE-2022-49084",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49084"
},
{
"name": "CVE-2022-49085",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49085"
},
{
"name": "CVE-2022-49086",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49086"
},
{
"name": "CVE-2022-49088",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49088"
},
{
"name": "CVE-2022-49090",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49090"
},
{
"name": "CVE-2022-49091",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49091"
},
{
"name": "CVE-2022-49092",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49092"
},
{
"name": "CVE-2022-49093",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49093"
},
{
"name": "CVE-2022-49095",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49095"
},
{
"name": "CVE-2022-49096",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49096"
},
{
"name": "CVE-2022-49097",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49097"
},
{
"name": "CVE-2022-49098",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49098"
},
{
"name": "CVE-2022-49099",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49099"
},
{
"name": "CVE-2022-49100",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49100"
},
{
"name": "CVE-2022-49102",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49102"
},
{
"name": "CVE-2022-49103",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49103"
},
{
"name": "CVE-2022-49104",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49104"
},
{
"name": "CVE-2022-49105",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49105"
},
{
"name": "CVE-2022-49106",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49106"
},
{
"name": "CVE-2022-49107",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49107"
},
{
"name": "CVE-2022-49109",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49109"
},
{
"name": "CVE-2022-49111",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49111"
},
{
"name": "CVE-2022-49112",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49112"
},
{
"name": "CVE-2022-49113",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49113"
},
{
"name": "CVE-2022-49114",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49114"
},
{
"name": "CVE-2022-49115",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49115"
},
{
"name": "CVE-2022-49116",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49116"
},
{
"name": "CVE-2022-49118",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49118"
},
{
"name": "CVE-2022-49119",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49119"
},
{
"name": "CVE-2022-49120",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49120"
},
{
"name": "CVE-2022-49121",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49121"
},
{
"name": "CVE-2022-49122",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49122"
},
{
"name": "CVE-2022-49126",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49126"
},
{
"name": "CVE-2022-49128",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49128"
},
{
"name": "CVE-2022-49129",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49129"
},
{
"name": "CVE-2022-49130",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49130"
},
{
"name": "CVE-2022-49131",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49131"
},
{
"name": "CVE-2022-49132",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49132"
},
{
"name": "CVE-2022-49137",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49137"
},
{
"name": "CVE-2022-49145",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49145"
},
{
"name": "CVE-2022-49147",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49147"
},
{
"name": "CVE-2022-49148",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49148"
},
{
"name": "CVE-2022-49153",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49153"
},
{
"name": "CVE-2022-49154",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49154"
},
{
"name": "CVE-2022-49155",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49155"
},
{
"name": "CVE-2022-49156",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49156"
},
{
"name": "CVE-2022-49157",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49157"
},
{
"name": "CVE-2022-49158",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49158"
},
{
"name": "CVE-2022-49159",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49159"
},
{
"name": "CVE-2022-49160",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49160"
},
{
"name": "CVE-2022-49162",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49162"
},
{
"name": "CVE-2022-49163",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49163"
},
{
"name": "CVE-2022-49164",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49164"
},
{
"name": "CVE-2022-49165",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49165"
},
{
"name": "CVE-2022-49174",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49174"
},
{
"name": "CVE-2022-49175",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49175"
},
{
"name": "CVE-2022-49176",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49176"
},
{
"name": "CVE-2022-49177",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49177"
},
{
"name": "CVE-2022-49179",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49179"
},
{
"name": "CVE-2022-49180",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49180"
},
{
"name": "CVE-2022-49185",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49185"
},
{
"name": "CVE-2022-49187",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49187"
},
{
"name": "CVE-2022-49188",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49188"
},
{
"name": "CVE-2022-49189",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49189"
},
{
"name": "CVE-2022-49193",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49193"
},
{
"name": "CVE-2022-49194",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49194"
},
{
"name": "CVE-2022-49196",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49196"
},
{
"name": "CVE-2022-49199",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49199"
},
{
"name": "CVE-2022-49200",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49200"
},
{
"name": "CVE-2022-49206",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49206"
},
{
"name": "CVE-2022-49208",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49208"
},
{
"name": "CVE-2022-49212",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49212"
},
{
"name": "CVE-2022-49213",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49213"
},
{
"name": "CVE-2022-49214",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49214"
},
{
"name": "CVE-2022-49216",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49216"
},
{
"name": "CVE-2022-49217",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49217"
},
{
"name": "CVE-2022-49218",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49218"
},
{
"name": "CVE-2022-49221",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49221"
},
{
"name": "CVE-2022-49222",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49222"
},
{
"name": "CVE-2022-49224",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49224"
},
{
"name": "CVE-2022-49226",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49226"
},
{
"name": "CVE-2022-49227",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49227"
},
{
"name": "CVE-2022-49232",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49232"
},
{
"name": "CVE-2022-49235",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49235"
},
{
"name": "CVE-2022-49236",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49236"
},
{
"name": "CVE-2022-49239",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49239"
},
{
"name": "CVE-2022-49241",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49241"
},
{
"name": "CVE-2022-49242",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49242"
},
{
"name": "CVE-2022-49243",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49243"
},
{
"name": "CVE-2022-49244",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49244"
},
{
"name": "CVE-2022-49246",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49246"
},
{
"name": "CVE-2022-49248",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49248"
},
{
"name": "CVE-2022-49249",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49249"
},
{
"name": "CVE-2022-49250",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49250"
},
{
"name": "CVE-2022-49251",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49251"
},
{
"name": "CVE-2022-49252",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49252"
},
{
"name": "CVE-2022-49253",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49253"
},
{
"name": "CVE-2022-49254",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49254"
},
{
"name": "CVE-2022-49256",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49256"
},
{
"name": "CVE-2022-49257",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49257"
},
{
"name": "CVE-2022-49258",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49258"
},
{
"name": "CVE-2022-49259",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49259"
},
{
"name": "CVE-2022-49260",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49260"
},
{
"name": "CVE-2022-49261",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49261"
},
{
"name": "CVE-2022-49262",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49262"
},
{
"name": "CVE-2022-49263",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49263"
},
{
"name": "CVE-2022-49264",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49264"
},
{
"name": "CVE-2022-49265",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49265"
},
{
"name": "CVE-2022-49266",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49266"
},
{
"name": "CVE-2022-49268",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49268"
},
{
"name": "CVE-2022-49269",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49269"
},
{
"name": "CVE-2022-49270",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49270"
},
{
"name": "CVE-2022-49271",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49271"
},
{
"name": "CVE-2022-49272",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49272"
},
{
"name": "CVE-2022-49273",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49273"
},
{
"name": "CVE-2022-49274",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49274"
},
{
"name": "CVE-2022-49275",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49275"
},
{
"name": "CVE-2022-49276",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49276"
},
{
"name": "CVE-2022-49277",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49277"
},
{
"name": "CVE-2022-49278",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49278"
},
{
"name": "CVE-2022-49279",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49279"
},
{
"name": "CVE-2022-49280",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49280"
},
{
"name": "CVE-2022-49281",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49281"
},
{
"name": "CVE-2022-49283",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49283"
},
{
"name": "CVE-2022-49285",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49285"
},
{
"name": "CVE-2022-49286",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49286"
},
{
"name": "CVE-2022-49287",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49287"
},
{
"name": "CVE-2022-49288",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49288"
},
{
"name": "CVE-2022-49290",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49290"
},
{
"name": "CVE-2022-49291",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49291"
},
{
"name": "CVE-2022-49292",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49292"
},
{
"name": "CVE-2022-49294",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49294"
},
{
"name": "CVE-2022-49295",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49295"
},
{
"name": "CVE-2022-49297",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49297"
},
{
"name": "CVE-2022-49298",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49298"
},
{
"name": "CVE-2022-49299",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49299"
},
{
"name": "CVE-2022-49300",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49300"
},
{
"name": "CVE-2022-49301",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49301"
},
{
"name": "CVE-2022-49302",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49302"
},
{
"name": "CVE-2022-49304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49304"
},
{
"name": "CVE-2022-49305",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49305"
},
{
"name": "CVE-2022-49307",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49307"
},
{
"name": "CVE-2022-49308",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49308"
},
{
"name": "CVE-2022-49309",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49309"
},
{
"name": "CVE-2022-49310",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49310"
},
{
"name": "CVE-2022-49311",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49311"
},
{
"name": "CVE-2022-49312",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49312"
},
{
"name": "CVE-2022-49313",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49313"
},
{
"name": "CVE-2022-49314",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49314"
},
{
"name": "CVE-2022-49315",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49315"
},
{
"name": "CVE-2022-49316",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49316"
},
{
"name": "CVE-2022-49319",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49319"
},
{
"name": "CVE-2022-49320",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49320"
},
{
"name": "CVE-2022-49321",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49321"
},
{
"name": "CVE-2022-49322",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49322"
},
{
"name": "CVE-2022-49323",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49323"
},
{
"name": "CVE-2022-49326",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49326"
},
{
"name": "CVE-2022-49327",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49327"
},
{
"name": "CVE-2022-49328",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49328"
},
{
"name": "CVE-2022-49331",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49331"
},
{
"name": "CVE-2022-49332",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49332"
},
{
"name": "CVE-2022-49335",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49335"
},
{
"name": "CVE-2022-49336",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49336"
},
{
"name": "CVE-2022-49337",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49337"
},
{
"name": "CVE-2022-49339",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49339"
},
{
"name": "CVE-2022-49341",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49341"
},
{
"name": "CVE-2022-49342",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49342"
},
{
"name": "CVE-2022-49343",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49343"
},
{
"name": "CVE-2022-49345",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49345"
},
{
"name": "CVE-2022-49346",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49346"
},
{
"name": "CVE-2022-49347",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49347"
},
{
"name": "CVE-2022-49348",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49348"
},
{
"name": "CVE-2022-49349",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49349"
},
{
"name": "CVE-2022-49350",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49350"
},
{
"name": "CVE-2022-49351",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49351"
},
{
"name": "CVE-2022-49352",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49352"
},
{
"name": "CVE-2022-49354",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49354"
},
{
"name": "CVE-2022-49356",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49356"
},
{
"name": "CVE-2022-49357",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49357"
},
{
"name": "CVE-2022-49367",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49367"
},
{
"name": "CVE-2022-49368",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49368"
},
{
"name": "CVE-2022-49370",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49370"
},
{
"name": "CVE-2022-49371",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49371"
},
{
"name": "CVE-2022-49373",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49373"
},
{
"name": "CVE-2022-49375",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49375"
},
{
"name": "CVE-2022-49376",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49376"
},
{
"name": "CVE-2022-49377",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49377"
},
{
"name": "CVE-2022-49378",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49378"
},
{
"name": "CVE-2022-49379",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49379"
},
{
"name": "CVE-2022-49381",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49381"
},
{
"name": "CVE-2022-49382",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49382"
},
{
"name": "CVE-2022-49384",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49384"
},
{
"name": "CVE-2022-49385",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49385"
},
{
"name": "CVE-2022-49386",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49386"
},
{
"name": "CVE-2022-49389",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49389"
},
{
"name": "CVE-2022-49392",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49392"
},
{
"name": "CVE-2022-49394",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49394"
},
{
"name": "CVE-2022-49396",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49396"
},
{
"name": "CVE-2022-49397",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49397"
},
{
"name": "CVE-2022-49398",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49398"
},
{
"name": "CVE-2022-49399",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49399"
},
{
"name": "CVE-2022-49400",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49400"
},
{
"name": "CVE-2022-49402",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49402"
},
{
"name": "CVE-2022-49404",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49404"
},
{
"name": "CVE-2022-49407",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49407"
},
{
"name": "CVE-2022-49409",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49409"
},
{
"name": "CVE-2022-49410",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49410"
},
{
"name": "CVE-2022-49411",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49411"
},
{
"name": "CVE-2022-49412",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49412"
},
{
"name": "CVE-2022-49413",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49413"
},
{
"name": "CVE-2022-49414",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49414"
},
{
"name": "CVE-2022-49416",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49416"
},
{
"name": "CVE-2022-49418",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49418"
},
{
"name": "CVE-2022-49421",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49421"
},
{
"name": "CVE-2022-49422",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49422"
},
{
"name": "CVE-2022-49424",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49424"
},
{
"name": "CVE-2022-49426",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49426"
},
{
"name": "CVE-2022-49427",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49427"
},
{
"name": "CVE-2022-49429",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49429"
},
{
"name": "CVE-2022-49430",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49430"
},
{
"name": "CVE-2022-49431",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49431"
},
{
"name": "CVE-2022-49432",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49432"
},
{
"name": "CVE-2022-49433",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49433"
},
{
"name": "CVE-2022-49434",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49434"
},
{
"name": "CVE-2022-49435",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49435"
},
{
"name": "CVE-2022-49437",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49437"
},
{
"name": "CVE-2022-49438",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49438"
},
{
"name": "CVE-2022-49440",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49440"
},
{
"name": "CVE-2022-49441",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49441"
},
{
"name": "CVE-2022-49442",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49442"
},
{
"name": "CVE-2022-49443",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49443"
},
{
"name": "CVE-2022-49444",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49444"
},
{
"name": "CVE-2022-49445",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49445"
},
{
"name": "CVE-2022-49447",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49447"
},
{
"name": "CVE-2022-49448",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49448"
},
{
"name": "CVE-2022-49449",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49449"
},
{
"name": "CVE-2022-49451",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49451"
},
{
"name": "CVE-2022-49453",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49453"
},
{
"name": "CVE-2022-49455",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49455"
},
{
"name": "CVE-2022-49459",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49459"
},
{
"name": "CVE-2022-49460",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49460"
},
{
"name": "CVE-2022-49462",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49462"
},
{
"name": "CVE-2022-49463",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49463"
},
{
"name": "CVE-2022-49466",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49466"
},
{
"name": "CVE-2022-49467",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49467"
},
{
"name": "CVE-2022-49468",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49468"
},
{
"name": "CVE-2022-49472",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49472"
},
{
"name": "CVE-2022-49473",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49473"
},
{
"name": "CVE-2022-49474",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49474"
},
{
"name": "CVE-2022-49475",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49475"
},
{
"name": "CVE-2022-49477",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49477"
},
{
"name": "CVE-2022-49478",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49478"
},
{
"name": "CVE-2022-49480",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49480"
},
{
"name": "CVE-2022-49481",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49481"
},
{
"name": "CVE-2022-49482",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49482"
},
{
"name": "CVE-2022-49486",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49486"
},
{
"name": "CVE-2022-49487",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49487"
},
{
"name": "CVE-2022-49488",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49488"
},
{
"name": "CVE-2022-49489",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49489"
},
{
"name": "CVE-2022-49491",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49491"
},
{
"name": "CVE-2022-49492",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49492"
},
{
"name": "CVE-2022-49493",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49493"
},
{
"name": "CVE-2022-49494",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49494"
},
{
"name": "CVE-2022-49495",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49495"
},
{
"name": "CVE-2022-49498",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49498"
},
{
"name": "CVE-2022-49501",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49501"
},
{
"name": "CVE-2022-49502",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49502"
},
{
"name": "CVE-2022-49503",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49503"
},
{
"name": "CVE-2022-49504",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49504"
},
{
"name": "CVE-2022-49505",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49505"
},
{
"name": "CVE-2022-49506",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49506"
},
{
"name": "CVE-2022-49507",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49507"
},
{
"name": "CVE-2022-49508",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49508"
},
{
"name": "CVE-2022-49509",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49509"
},
{
"name": "CVE-2022-49512",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49512"
},
{
"name": "CVE-2022-49514",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49514"
},
{
"name": "CVE-2022-49515",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49515"
},
{
"name": "CVE-2022-49517",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49517"
},
{
"name": "CVE-2022-49519",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49519"
},
{
"name": "CVE-2022-49520",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49520"
},
{
"name": "CVE-2022-49521",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49521"
},
{
"name": "CVE-2022-49522",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49522"
},
{
"name": "CVE-2022-49523",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49523"
},
{
"name": "CVE-2022-49524",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49524"
},
{
"name": "CVE-2022-49525",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49525"
},
{
"name": "CVE-2022-49526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49526"
},
{
"name": "CVE-2022-49527",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49527"
},
{
"name": "CVE-2022-49532",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49532"
},
{
"name": "CVE-2022-49534",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49534"
},
{
"name": "CVE-2022-49535",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49535"
},
{
"name": "CVE-2022-49536",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49536"
},
{
"name": "CVE-2022-49537",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49537"
},
{
"name": "CVE-2022-49541",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49541"
},
{
"name": "CVE-2022-49542",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49542"
},
{
"name": "CVE-2022-49544",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49544"
},
{
"name": "CVE-2022-49545",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49545"
},
{
"name": "CVE-2022-49546",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49546"
},
{
"name": "CVE-2022-49549",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49549"
},
{
"name": "CVE-2022-49551",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49551"
},
{
"name": "CVE-2022-49555",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49555"
},
{
"name": "CVE-2022-49556",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49556"
},
{
"name": "CVE-2022-49559",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49559"
},
{
"name": "CVE-2022-49562",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49562"
},
{
"name": "CVE-2022-49563",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49563"
},
{
"name": "CVE-2022-49564",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49564"
},
{
"name": "CVE-2022-49566",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49566"
},
{
"name": "CVE-2022-49568",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49568"
},
{
"name": "CVE-2022-49569",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49569"
},
{
"name": "CVE-2022-49570",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49570"
},
{
"name": "CVE-2022-49579",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49579"
},
{
"name": "CVE-2022-49581",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49581"
},
{
"name": "CVE-2022-49583",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49583"
},
{
"name": "CVE-2022-49584",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49584"
},
{
"name": "CVE-2022-49591",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49591"
},
{
"name": "CVE-2022-49592",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49592"
},
{
"name": "CVE-2022-49603",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49603"
},
{
"name": "CVE-2022-49605",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49605"
},
{
"name": "CVE-2022-49606",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49606"
},
{
"name": "CVE-2022-49607",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49607"
},
{
"name": "CVE-2022-49609",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49609"
},
{
"name": "CVE-2022-49610",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49610"
},
{
"name": "CVE-2022-49611",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49611"
},
{
"name": "CVE-2022-49613",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49613"
},
{
"name": "CVE-2022-49615",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49615"
},
{
"name": "CVE-2022-49616",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49616"
},
{
"name": "CVE-2022-49617",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49617"
},
{
"name": "CVE-2022-49618",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49618"
},
{
"name": "CVE-2022-49621",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49621"
},
{
"name": "CVE-2022-49623",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49623"
},
{
"name": "CVE-2022-49625",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49625"
},
{
"name": "CVE-2022-49627",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49627"
},
{
"name": "CVE-2022-49628",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49628"
},
{
"name": "CVE-2022-49631",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49631"
},
{
"name": "CVE-2022-49634",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49634"
},
{
"name": "CVE-2022-49640",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49640"
},
{
"name": "CVE-2022-49641",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49641"
},
{
"name": "CVE-2022-49642",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49642"
},
{
"name": "CVE-2022-49643",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49643"
},
{
"name": "CVE-2022-49644",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49644"
},
{
"name": "CVE-2022-49645",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49645"
},
{
"name": "CVE-2022-49646",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49646"
},
{
"name": "CVE-2022-49647",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49647"
},
{
"name": "CVE-2022-49648",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49648"
},
{
"name": "CVE-2022-49649",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49649"
},
{
"name": "CVE-2022-49652",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49652"
},
{
"name": "CVE-2022-49653",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49653"
},
{
"name": "CVE-2022-49656",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49656"
},
{
"name": "CVE-2022-49657",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49657"
},
{
"name": "CVE-2022-49663",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49663"
},
{
"name": "CVE-2022-49665",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49665"
},
{
"name": "CVE-2022-49667",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49667"
},
{
"name": "CVE-2022-49668",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49668"
},
{
"name": "CVE-2022-49670",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49670"
},
{
"name": "CVE-2022-49671",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49671"
},
{
"name": "CVE-2022-49672",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49672"
},
{
"name": "CVE-2022-49673",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49673"
},
{
"name": "CVE-2022-49674",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49674"
},
{
"name": "CVE-2022-49675",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49675"
},
{
"name": "CVE-2022-49676",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49676"
},
{
"name": "CVE-2022-49677",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49677"
},
{
"name": "CVE-2022-49678",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49678"
},
{
"name": "CVE-2022-49679",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49679"
},
{
"name": "CVE-2022-49680",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49680"
},
{
"name": "CVE-2022-49683",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49683"
},
{
"name": "CVE-2022-49685",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49685"
},
{
"name": "CVE-2022-49687",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49687"
},
{
"name": "CVE-2022-49688",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49688"
},
{
"name": "CVE-2022-49693",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49693"
},
{
"name": "CVE-2022-49695",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49695"
},
{
"name": "CVE-2022-49699",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49699"
},
{
"name": "CVE-2022-49700",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49700"
},
{
"name": "CVE-2022-49701",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49701"
},
{
"name": "CVE-2022-49703",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49703"
},
{
"name": "CVE-2022-49704",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49704"
},
{
"name": "CVE-2022-49705",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49705"
},
{
"name": "CVE-2022-49707",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49707"
},
{
"name": "CVE-2022-49708",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49708"
},
{
"name": "CVE-2022-49710",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49710"
},
{
"name": "CVE-2022-49711",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49711"
},
{
"name": "CVE-2022-49712",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49712"
},
{
"name": "CVE-2022-49713",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49713"
},
{
"name": "CVE-2022-49714",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49714"
},
{
"name": "CVE-2022-49715",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49715"
},
{
"name": "CVE-2022-49716",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49716"
},
{
"name": "CVE-2022-49719",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49719"
},
{
"name": "CVE-2022-49720",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49720"
},
{
"name": "CVE-2022-49721",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49721"
},
{
"name": "CVE-2022-49722",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49722"
},
{
"name": "CVE-2022-49723",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49723"
},
{
"name": "CVE-2022-49724",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49724"
},
{
"name": "CVE-2022-49725",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49725"
},
{
"name": "CVE-2022-49726",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49726"
},
{
"name": "CVE-2022-49729",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49729"
},
{
"name": "CVE-2022-49730",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49730"
},
{
"name": "CVE-2022-49731",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49731"
},
{
"name": "CVE-2022-49733",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49733"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2025-21772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21772"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2024-58013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58013"
},
{
"name": "CVE-2024-58052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58052"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2025-21703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21703"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2025-21762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21762"
},
{
"name": "CVE-2025-21763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21763"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2025-21766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21766"
},
{
"name": "CVE-2025-21776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21776"
},
{
"name": "CVE-2025-21782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21782"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2025-21821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21821"
},
{
"name": "CVE-2021-4454",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4454"
},
{
"name": "CVE-2022-49053",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49053"
},
{
"name": "CVE-2022-49056",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49056"
},
{
"name": "CVE-2022-49057",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49057"
},
{
"name": "CVE-2022-49062",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49062"
},
{
"name": "CVE-2022-49064",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49064"
},
{
"name": "CVE-2022-49070",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49070"
},
{
"name": "CVE-2022-49071",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49071"
},
{
"name": "CVE-2022-49075",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49075"
},
{
"name": "CVE-2022-49123",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49123"
},
{
"name": "CVE-2022-49125",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49125"
},
{
"name": "CVE-2022-49133",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49133"
},
{
"name": "CVE-2022-49136",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49136"
},
{
"name": "CVE-2022-49138",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49138"
},
{
"name": "CVE-2022-49139",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49139"
},
{
"name": "CVE-2022-49144",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49144"
},
{
"name": "CVE-2022-49183",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49183"
},
{
"name": "CVE-2022-49192",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49192"
},
{
"name": "CVE-2022-49202",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49202"
},
{
"name": "CVE-2022-49203",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49203"
},
{
"name": "CVE-2022-49204",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49204"
},
{
"name": "CVE-2022-49205",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49205"
},
{
"name": "CVE-2022-49207",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49207"
},
{
"name": "CVE-2022-49209",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49209"
},
{
"name": "CVE-2022-49215",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49215"
},
{
"name": "CVE-2022-49219",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49219"
},
{
"name": "CVE-2022-49225",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49225"
},
{
"name": "CVE-2022-49228",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49228"
},
{
"name": "CVE-2022-49230",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49230"
},
{
"name": "CVE-2022-49233",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49233"
},
{
"name": "CVE-2022-49237",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49237"
},
{
"name": "CVE-2022-49238",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49238"
},
{
"name": "CVE-2022-49293",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49293"
},
{
"name": "CVE-2022-49296",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49296"
},
{
"name": "CVE-2022-49306",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49306"
},
{
"name": "CVE-2022-49325",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49325"
},
{
"name": "CVE-2022-49329",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49329"
},
{
"name": "CVE-2022-49330",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49330"
},
{
"name": "CVE-2022-49333",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49333"
},
{
"name": "CVE-2022-49338",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49338"
},
{
"name": "CVE-2022-49353",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49353"
},
{
"name": "CVE-2022-49359",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49359"
},
{
"name": "CVE-2022-49362",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49362"
},
{
"name": "CVE-2022-49365",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49365"
},
{
"name": "CVE-2022-49390",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49390"
},
{
"name": "CVE-2022-49406",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49406"
},
{
"name": "CVE-2022-49419",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49419"
},
{
"name": "CVE-2022-49436",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49436"
},
{
"name": "CVE-2022-49446",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49446"
},
{
"name": "CVE-2022-49458",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49458"
},
{
"name": "CVE-2022-49465",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49465"
},
{
"name": "CVE-2022-49470",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49470"
},
{
"name": "CVE-2022-49476",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49476"
},
{
"name": "CVE-2022-49479",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49479"
},
{
"name": "CVE-2022-49483",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49483"
},
{
"name": "CVE-2022-49484",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49484"
},
{
"name": "CVE-2022-49485",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49485"
},
{
"name": "CVE-2022-49497",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49497"
},
{
"name": "CVE-2022-49499",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49499"
},
{
"name": "CVE-2022-49510",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49510"
},
{
"name": "CVE-2022-49511",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49511"
},
{
"name": "CVE-2022-49516",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49516"
},
{
"name": "CVE-2022-49518",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49518"
},
{
"name": "CVE-2022-49529",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49529"
},
{
"name": "CVE-2022-49530",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49530"
},
{
"name": "CVE-2022-49533",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49533"
},
{
"name": "CVE-2022-49538",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49538"
},
{
"name": "CVE-2022-49543",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49543"
},
{
"name": "CVE-2022-49548",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49548"
},
{
"name": "CVE-2022-49552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49552"
},
{
"name": "CVE-2022-49560",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49560"
},
{
"name": "CVE-2022-49565",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49565"
},
{
"name": "CVE-2022-49624",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49624"
},
{
"name": "CVE-2022-49635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49635"
},
{
"name": "CVE-2022-49638",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49638"
},
{
"name": "CVE-2022-49650",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49650"
},
{
"name": "CVE-2022-49655",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49655"
},
{
"name": "CVE-2022-49658",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49658"
},
{
"name": "CVE-2022-49686",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49686"
},
{
"name": "CVE-2022-49694",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49694"
},
{
"name": "CVE-2022-49697",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49697"
},
{
"name": "CVE-2022-49732",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49732"
},
{
"name": "CVE-2022-49739",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49739"
},
{
"name": "CVE-2022-49746",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49746"
},
{
"name": "CVE-2022-49748",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49748"
},
{
"name": "CVE-2022-49751",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49751"
},
{
"name": "CVE-2022-49753",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49753"
},
{
"name": "CVE-2022-49755",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49755"
},
{
"name": "CVE-2022-49759",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49759"
},
{
"name": "CVE-2023-52930",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52930"
},
{
"name": "CVE-2023-52933",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52933"
},
{
"name": "CVE-2023-52935",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52935"
},
{
"name": "CVE-2023-52939",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52939"
},
{
"name": "CVE-2023-52941",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52941"
},
{
"name": "CVE-2023-52973",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52973"
},
{
"name": "CVE-2023-52974",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52974"
},
{
"name": "CVE-2023-52975",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52975"
},
{
"name": "CVE-2023-52976",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52976"
},
{
"name": "CVE-2023-52979",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52979"
},
{
"name": "CVE-2023-52983",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52983"
},
{
"name": "CVE-2023-52984",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52984"
},
{
"name": "CVE-2023-52988",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52988"
},
{
"name": "CVE-2023-52989",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52989"
},
{
"name": "CVE-2023-52992",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52992"
},
{
"name": "CVE-2023-52993",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52993"
},
{
"name": "CVE-2023-53000",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53000"
},
{
"name": "CVE-2023-53005",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53005"
},
{
"name": "CVE-2023-53006",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53006"
},
{
"name": "CVE-2023-53007",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53007"
},
{
"name": "CVE-2023-53008",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53008"
},
{
"name": "CVE-2023-53010",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53010"
},
{
"name": "CVE-2023-53015",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53015"
},
{
"name": "CVE-2023-53016",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53016"
},
{
"name": "CVE-2023-53019",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53019"
},
{
"name": "CVE-2023-53023",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53023"
},
{
"name": "CVE-2023-53024",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53024"
},
{
"name": "CVE-2023-53025",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53025"
},
{
"name": "CVE-2023-53026",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53026"
},
{
"name": "CVE-2023-53028",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53028"
},
{
"name": "CVE-2023-53029",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53029"
},
{
"name": "CVE-2023-53030",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53030"
},
{
"name": "CVE-2023-53033",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53033"
},
{
"name": "CVE-2025-21693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21693"
},
{
"name": "CVE-2025-21759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21759"
},
{
"name": "CVE-2025-21831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21831"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2025-21848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21848"
},
{
"name": "CVE-2025-21855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21855"
},
{
"name": "CVE-2025-21858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21858"
},
{
"name": "CVE-2025-21865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21865"
},
{
"name": "CVE-2025-21871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21871"
},
{
"name": "CVE-2025-21877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21877"
},
{
"name": "CVE-2025-21891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21891"
},
{
"name": "CVE-2025-21916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21916"
},
{
"name": "CVE-2025-21922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21922"
},
{
"name": "CVE-2025-21934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21934"
},
{
"name": "CVE-2025-21935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21935"
},
{
"name": "CVE-2025-21993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21993"
},
{
"name": "CVE-2025-21996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21996"
},
{
"name": "CVE-2025-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22007"
},
{
"name": "CVE-2022-49046",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49046"
},
{
"name": "CVE-2022-49191",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49191"
},
{
"name": "CVE-2022-49220",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49220"
},
{
"name": "CVE-2022-49344",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49344"
},
{
"name": "CVE-2022-49372",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49372"
},
{
"name": "CVE-2022-49388",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49388"
},
{
"name": "CVE-2022-49395",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49395"
},
{
"name": "CVE-2022-49513",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49513"
},
{
"name": "CVE-2022-49578",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49578"
},
{
"name": "CVE-2022-49589",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49589"
},
{
"name": "CVE-2022-49619",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49619"
},
{
"name": "CVE-2022-49620",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49620"
},
{
"name": "CVE-2022-49727",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49727"
},
{
"name": "CVE-2022-49740",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49740"
},
{
"name": "CVE-2023-52997",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52997"
},
{
"name": "CVE-2023-53031",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53031"
},
{
"name": "CVE-2025-21969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21969"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0336",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-04-18T00:00:00.000000"
}
],
"risks": [
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de SUSE. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de SUSE",
"vendor_advisories": [
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1225-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251225-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1232-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251232-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1248-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251248-1"
},
{
"published_at": "2025-04-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1276-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251276-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1259-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251259-1"
},
{
"published_at": "2025-04-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1262-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251262-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1241-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251241-1"
},
{
"published_at": "2025-04-13",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1207-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251207-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1236-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251236-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1260-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251260-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1213-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251213-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1252-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251252-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1238-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251238-1"
},
{
"published_at": "2025-04-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1275-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251275-1"
},
{
"published_at": "2025-04-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1278-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251278-1"
},
{
"published_at": "2025-04-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1263-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251263-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1254-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251254-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1257-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251257-1"
},
{
"published_at": "2025-04-13",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1214-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251214-1"
},
{
"published_at": "2025-04-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1293-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251293-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1231-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251231-1"
}
]
}
CERTFR-2025-AVI-0336
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et une atteinte à la confidentialité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP5 | ||
| SUSE | N/A | SUSE Manager Proxy 4.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.3 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 LTSS | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP3 | ||
| SUSE | N/A | openSUSE Leap 15.4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP4 | ||
| SUSE | N/A | openSUSE Leap 15.5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 Business Critical Linux | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 12-SP5 | ||
| SUSE | N/A | SUSE Manager Retail Branch Server 4.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing LTSS 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP6 | ||
| SUSE | N/A | openSUSE Leap 15.6 | ||
| SUSE | N/A | SUSE Enterprise Storage 7.1 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP5 LTSS | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing ESPOS 15 SP5 | ||
| SUSE | N/A | SUSE Manager Server 4.2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 LTSS | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.1 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.4 | ||
| SUSE | N/A | openSUSE Leap 15.3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 LTSS Extended Security | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.5 |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5 LTSS",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3 Business Critical Linux",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 12-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Retail Branch Server 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Enterprise Storage 7.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP5 LTSS",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing ESPOS 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3 LTSS",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5 LTSS Extended Security",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2017-5753",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-5753"
},
{
"name": "CVE-2020-27835",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27835"
},
{
"name": "CVE-2022-1016",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1016"
},
{
"name": "CVE-2022-1184",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1184"
},
{
"name": "CVE-2022-1048",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1048"
},
{
"name": "CVE-2022-26373",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26373"
},
{
"name": "CVE-2022-0168",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0168"
},
{
"name": "CVE-2022-3435",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3435"
},
{
"name": "CVE-2022-29901",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29901"
},
{
"name": "CVE-2022-29900",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29900"
},
{
"name": "CVE-2022-2977",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2977"
},
{
"name": "CVE-2022-3303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3303"
},
{
"name": "CVE-2023-0179",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0179"
},
{
"name": "CVE-2023-1652",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1652"
},
{
"name": "CVE-2023-28410",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28410"
},
{
"name": "CVE-2023-2162",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2162"
},
{
"name": "CVE-2023-3567",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3567"
},
{
"name": "CVE-2021-46925",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46925"
},
{
"name": "CVE-2024-26634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26634"
},
{
"name": "CVE-2021-47248",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47248"
},
{
"name": "CVE-2024-35910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35910"
},
{
"name": "CVE-2024-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38559"
},
{
"name": "CVE-2024-41005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41005"
},
{
"name": "CVE-2024-36968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36968"
},
{
"name": "CVE-2024-41090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41090"
},
{
"name": "CVE-2021-47517",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47517"
},
{
"name": "CVE-2022-49014",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49014"
},
{
"name": "CVE-2024-49935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49935"
},
{
"name": "CVE-2024-50269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50269"
},
{
"name": "CVE-2024-50290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50290"
},
{
"name": "CVE-2024-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53063"
},
{
"name": "CVE-2024-47678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47678"
},
{
"name": "CVE-2024-53140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53140"
},
{
"name": "CVE-2024-56642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56642"
},
{
"name": "CVE-2024-56651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56651"
},
{
"name": "CVE-2024-56600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56600"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2024-56633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56633"
},
{
"name": "CVE-2024-49940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49940"
},
{
"name": "CVE-2024-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53176"
},
{
"name": "CVE-2024-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53178"
},
{
"name": "CVE-2024-49571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49571"
},
{
"name": "CVE-2024-53680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53680"
},
{
"name": "CVE-2024-56640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56640"
},
{
"name": "CVE-2024-56770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56770"
},
{
"name": "CVE-2024-57900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57900"
},
{
"name": "CVE-2021-47633",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47633"
},
{
"name": "CVE-2021-47644",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47644"
},
{
"name": "CVE-2022-49076",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49076"
},
{
"name": "CVE-2022-49089",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49089"
},
{
"name": "CVE-2022-49134",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49134"
},
{
"name": "CVE-2022-49135",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49135"
},
{
"name": "CVE-2022-49151",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49151"
},
{
"name": "CVE-2022-49178",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49178"
},
{
"name": "CVE-2022-49182",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49182"
},
{
"name": "CVE-2022-49201",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49201"
},
{
"name": "CVE-2022-49247",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49247"
},
{
"name": "CVE-2022-49490",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49490"
},
{
"name": "CVE-2022-49626",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49626"
},
{
"name": "CVE-2022-49661",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49661"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2025-21802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21802"
},
{
"name": "CVE-2021-4453",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4453"
},
{
"name": "CVE-2021-47631",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47631"
},
{
"name": "CVE-2021-47632",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47632"
},
{
"name": "CVE-2021-47635",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47635"
},
{
"name": "CVE-2021-47636",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47636"
},
{
"name": "CVE-2021-47637",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47637"
},
{
"name": "CVE-2021-47638",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47638"
},
{
"name": "CVE-2021-47639",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47639"
},
{
"name": "CVE-2021-47641",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47641"
},
{
"name": "CVE-2021-47642",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47642"
},
{
"name": "CVE-2021-47643",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47643"
},
{
"name": "CVE-2021-47645",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47645"
},
{
"name": "CVE-2021-47646",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47646"
},
{
"name": "CVE-2021-47647",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47647"
},
{
"name": "CVE-2021-47648",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47648"
},
{
"name": "CVE-2021-47649",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47649"
},
{
"name": "CVE-2021-47650",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47650"
},
{
"name": "CVE-2021-47651",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47651"
},
{
"name": "CVE-2021-47652",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47652"
},
{
"name": "CVE-2021-47653",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47653"
},
{
"name": "CVE-2021-47654",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47654"
},
{
"name": "CVE-2021-47656",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47656"
},
{
"name": "CVE-2021-47657",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47657"
},
{
"name": "CVE-2021-47659",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47659"
},
{
"name": "CVE-2022-0995",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0995"
},
{
"name": "CVE-2022-49044",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49044"
},
{
"name": "CVE-2022-49050",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49050"
},
{
"name": "CVE-2022-49051",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49051"
},
{
"name": "CVE-2022-49054",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49054"
},
{
"name": "CVE-2022-49055",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49055"
},
{
"name": "CVE-2022-49058",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49058"
},
{
"name": "CVE-2022-49059",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49059"
},
{
"name": "CVE-2022-49060",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49060"
},
{
"name": "CVE-2022-49061",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49061"
},
{
"name": "CVE-2022-49063",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49063"
},
{
"name": "CVE-2022-49065",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49065"
},
{
"name": "CVE-2022-49066",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49066"
},
{
"name": "CVE-2022-49073",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49073"
},
{
"name": "CVE-2022-49074",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49074"
},
{
"name": "CVE-2022-49078",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49078"
},
{
"name": "CVE-2022-49082",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49082"
},
{
"name": "CVE-2022-49083",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49083"
},
{
"name": "CVE-2022-49084",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49084"
},
{
"name": "CVE-2022-49085",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49085"
},
{
"name": "CVE-2022-49086",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49086"
},
{
"name": "CVE-2022-49088",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49088"
},
{
"name": "CVE-2022-49090",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49090"
},
{
"name": "CVE-2022-49091",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49091"
},
{
"name": "CVE-2022-49092",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49092"
},
{
"name": "CVE-2022-49093",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49093"
},
{
"name": "CVE-2022-49095",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49095"
},
{
"name": "CVE-2022-49096",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49096"
},
{
"name": "CVE-2022-49097",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49097"
},
{
"name": "CVE-2022-49098",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49098"
},
{
"name": "CVE-2022-49099",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49099"
},
{
"name": "CVE-2022-49100",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49100"
},
{
"name": "CVE-2022-49102",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49102"
},
{
"name": "CVE-2022-49103",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49103"
},
{
"name": "CVE-2022-49104",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49104"
},
{
"name": "CVE-2022-49105",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49105"
},
{
"name": "CVE-2022-49106",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49106"
},
{
"name": "CVE-2022-49107",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49107"
},
{
"name": "CVE-2022-49109",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49109"
},
{
"name": "CVE-2022-49111",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49111"
},
{
"name": "CVE-2022-49112",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49112"
},
{
"name": "CVE-2022-49113",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49113"
},
{
"name": "CVE-2022-49114",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49114"
},
{
"name": "CVE-2022-49115",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49115"
},
{
"name": "CVE-2022-49116",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49116"
},
{
"name": "CVE-2022-49118",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49118"
},
{
"name": "CVE-2022-49119",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49119"
},
{
"name": "CVE-2022-49120",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49120"
},
{
"name": "CVE-2022-49121",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49121"
},
{
"name": "CVE-2022-49122",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49122"
},
{
"name": "CVE-2022-49126",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49126"
},
{
"name": "CVE-2022-49128",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49128"
},
{
"name": "CVE-2022-49129",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49129"
},
{
"name": "CVE-2022-49130",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49130"
},
{
"name": "CVE-2022-49131",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49131"
},
{
"name": "CVE-2022-49132",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49132"
},
{
"name": "CVE-2022-49137",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49137"
},
{
"name": "CVE-2022-49145",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49145"
},
{
"name": "CVE-2022-49147",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49147"
},
{
"name": "CVE-2022-49148",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49148"
},
{
"name": "CVE-2022-49153",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49153"
},
{
"name": "CVE-2022-49154",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49154"
},
{
"name": "CVE-2022-49155",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49155"
},
{
"name": "CVE-2022-49156",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49156"
},
{
"name": "CVE-2022-49157",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49157"
},
{
"name": "CVE-2022-49158",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49158"
},
{
"name": "CVE-2022-49159",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49159"
},
{
"name": "CVE-2022-49160",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49160"
},
{
"name": "CVE-2022-49162",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49162"
},
{
"name": "CVE-2022-49163",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49163"
},
{
"name": "CVE-2022-49164",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49164"
},
{
"name": "CVE-2022-49165",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49165"
},
{
"name": "CVE-2022-49174",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49174"
},
{
"name": "CVE-2022-49175",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49175"
},
{
"name": "CVE-2022-49176",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49176"
},
{
"name": "CVE-2022-49177",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49177"
},
{
"name": "CVE-2022-49179",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49179"
},
{
"name": "CVE-2022-49180",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49180"
},
{
"name": "CVE-2022-49185",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49185"
},
{
"name": "CVE-2022-49187",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49187"
},
{
"name": "CVE-2022-49188",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49188"
},
{
"name": "CVE-2022-49189",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49189"
},
{
"name": "CVE-2022-49193",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49193"
},
{
"name": "CVE-2022-49194",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49194"
},
{
"name": "CVE-2022-49196",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49196"
},
{
"name": "CVE-2022-49199",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49199"
},
{
"name": "CVE-2022-49200",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49200"
},
{
"name": "CVE-2022-49206",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49206"
},
{
"name": "CVE-2022-49208",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49208"
},
{
"name": "CVE-2022-49212",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49212"
},
{
"name": "CVE-2022-49213",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49213"
},
{
"name": "CVE-2022-49214",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49214"
},
{
"name": "CVE-2022-49216",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49216"
},
{
"name": "CVE-2022-49217",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49217"
},
{
"name": "CVE-2022-49218",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49218"
},
{
"name": "CVE-2022-49221",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49221"
},
{
"name": "CVE-2022-49222",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49222"
},
{
"name": "CVE-2022-49224",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49224"
},
{
"name": "CVE-2022-49226",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49226"
},
{
"name": "CVE-2022-49227",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49227"
},
{
"name": "CVE-2022-49232",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49232"
},
{
"name": "CVE-2022-49235",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49235"
},
{
"name": "CVE-2022-49236",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49236"
},
{
"name": "CVE-2022-49239",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49239"
},
{
"name": "CVE-2022-49241",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49241"
},
{
"name": "CVE-2022-49242",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49242"
},
{
"name": "CVE-2022-49243",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49243"
},
{
"name": "CVE-2022-49244",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49244"
},
{
"name": "CVE-2022-49246",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49246"
},
{
"name": "CVE-2022-49248",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49248"
},
{
"name": "CVE-2022-49249",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49249"
},
{
"name": "CVE-2022-49250",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49250"
},
{
"name": "CVE-2022-49251",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49251"
},
{
"name": "CVE-2022-49252",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49252"
},
{
"name": "CVE-2022-49253",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49253"
},
{
"name": "CVE-2022-49254",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49254"
},
{
"name": "CVE-2022-49256",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49256"
},
{
"name": "CVE-2022-49257",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49257"
},
{
"name": "CVE-2022-49258",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49258"
},
{
"name": "CVE-2022-49259",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49259"
},
{
"name": "CVE-2022-49260",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49260"
},
{
"name": "CVE-2022-49261",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49261"
},
{
"name": "CVE-2022-49262",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49262"
},
{
"name": "CVE-2022-49263",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49263"
},
{
"name": "CVE-2022-49264",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49264"
},
{
"name": "CVE-2022-49265",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49265"
},
{
"name": "CVE-2022-49266",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49266"
},
{
"name": "CVE-2022-49268",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49268"
},
{
"name": "CVE-2022-49269",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49269"
},
{
"name": "CVE-2022-49270",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49270"
},
{
"name": "CVE-2022-49271",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49271"
},
{
"name": "CVE-2022-49272",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49272"
},
{
"name": "CVE-2022-49273",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49273"
},
{
"name": "CVE-2022-49274",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49274"
},
{
"name": "CVE-2022-49275",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49275"
},
{
"name": "CVE-2022-49276",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49276"
},
{
"name": "CVE-2022-49277",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49277"
},
{
"name": "CVE-2022-49278",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49278"
},
{
"name": "CVE-2022-49279",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49279"
},
{
"name": "CVE-2022-49280",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49280"
},
{
"name": "CVE-2022-49281",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49281"
},
{
"name": "CVE-2022-49283",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49283"
},
{
"name": "CVE-2022-49285",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49285"
},
{
"name": "CVE-2022-49286",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49286"
},
{
"name": "CVE-2022-49287",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49287"
},
{
"name": "CVE-2022-49288",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49288"
},
{
"name": "CVE-2022-49290",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49290"
},
{
"name": "CVE-2022-49291",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49291"
},
{
"name": "CVE-2022-49292",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49292"
},
{
"name": "CVE-2022-49294",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49294"
},
{
"name": "CVE-2022-49295",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49295"
},
{
"name": "CVE-2022-49297",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49297"
},
{
"name": "CVE-2022-49298",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49298"
},
{
"name": "CVE-2022-49299",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49299"
},
{
"name": "CVE-2022-49300",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49300"
},
{
"name": "CVE-2022-49301",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49301"
},
{
"name": "CVE-2022-49302",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49302"
},
{
"name": "CVE-2022-49304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49304"
},
{
"name": "CVE-2022-49305",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49305"
},
{
"name": "CVE-2022-49307",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49307"
},
{
"name": "CVE-2022-49308",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49308"
},
{
"name": "CVE-2022-49309",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49309"
},
{
"name": "CVE-2022-49310",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49310"
},
{
"name": "CVE-2022-49311",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49311"
},
{
"name": "CVE-2022-49312",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49312"
},
{
"name": "CVE-2022-49313",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49313"
},
{
"name": "CVE-2022-49314",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49314"
},
{
"name": "CVE-2022-49315",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49315"
},
{
"name": "CVE-2022-49316",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49316"
},
{
"name": "CVE-2022-49319",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49319"
},
{
"name": "CVE-2022-49320",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49320"
},
{
"name": "CVE-2022-49321",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49321"
},
{
"name": "CVE-2022-49322",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49322"
},
{
"name": "CVE-2022-49323",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49323"
},
{
"name": "CVE-2022-49326",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49326"
},
{
"name": "CVE-2022-49327",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49327"
},
{
"name": "CVE-2022-49328",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49328"
},
{
"name": "CVE-2022-49331",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49331"
},
{
"name": "CVE-2022-49332",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49332"
},
{
"name": "CVE-2022-49335",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49335"
},
{
"name": "CVE-2022-49336",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49336"
},
{
"name": "CVE-2022-49337",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49337"
},
{
"name": "CVE-2022-49339",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49339"
},
{
"name": "CVE-2022-49341",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49341"
},
{
"name": "CVE-2022-49342",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49342"
},
{
"name": "CVE-2022-49343",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49343"
},
{
"name": "CVE-2022-49345",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49345"
},
{
"name": "CVE-2022-49346",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49346"
},
{
"name": "CVE-2022-49347",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49347"
},
{
"name": "CVE-2022-49348",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49348"
},
{
"name": "CVE-2022-49349",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49349"
},
{
"name": "CVE-2022-49350",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49350"
},
{
"name": "CVE-2022-49351",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49351"
},
{
"name": "CVE-2022-49352",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49352"
},
{
"name": "CVE-2022-49354",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49354"
},
{
"name": "CVE-2022-49356",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49356"
},
{
"name": "CVE-2022-49357",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49357"
},
{
"name": "CVE-2022-49367",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49367"
},
{
"name": "CVE-2022-49368",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49368"
},
{
"name": "CVE-2022-49370",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49370"
},
{
"name": "CVE-2022-49371",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49371"
},
{
"name": "CVE-2022-49373",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49373"
},
{
"name": "CVE-2022-49375",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49375"
},
{
"name": "CVE-2022-49376",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49376"
},
{
"name": "CVE-2022-49377",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49377"
},
{
"name": "CVE-2022-49378",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49378"
},
{
"name": "CVE-2022-49379",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49379"
},
{
"name": "CVE-2022-49381",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49381"
},
{
"name": "CVE-2022-49382",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49382"
},
{
"name": "CVE-2022-49384",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49384"
},
{
"name": "CVE-2022-49385",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49385"
},
{
"name": "CVE-2022-49386",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49386"
},
{
"name": "CVE-2022-49389",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49389"
},
{
"name": "CVE-2022-49392",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49392"
},
{
"name": "CVE-2022-49394",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49394"
},
{
"name": "CVE-2022-49396",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49396"
},
{
"name": "CVE-2022-49397",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49397"
},
{
"name": "CVE-2022-49398",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49398"
},
{
"name": "CVE-2022-49399",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49399"
},
{
"name": "CVE-2022-49400",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49400"
},
{
"name": "CVE-2022-49402",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49402"
},
{
"name": "CVE-2022-49404",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49404"
},
{
"name": "CVE-2022-49407",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49407"
},
{
"name": "CVE-2022-49409",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49409"
},
{
"name": "CVE-2022-49410",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49410"
},
{
"name": "CVE-2022-49411",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49411"
},
{
"name": "CVE-2022-49412",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49412"
},
{
"name": "CVE-2022-49413",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49413"
},
{
"name": "CVE-2022-49414",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49414"
},
{
"name": "CVE-2022-49416",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49416"
},
{
"name": "CVE-2022-49418",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49418"
},
{
"name": "CVE-2022-49421",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49421"
},
{
"name": "CVE-2022-49422",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49422"
},
{
"name": "CVE-2022-49424",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49424"
},
{
"name": "CVE-2022-49426",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49426"
},
{
"name": "CVE-2022-49427",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49427"
},
{
"name": "CVE-2022-49429",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49429"
},
{
"name": "CVE-2022-49430",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49430"
},
{
"name": "CVE-2022-49431",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49431"
},
{
"name": "CVE-2022-49432",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49432"
},
{
"name": "CVE-2022-49433",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49433"
},
{
"name": "CVE-2022-49434",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49434"
},
{
"name": "CVE-2022-49435",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49435"
},
{
"name": "CVE-2022-49437",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49437"
},
{
"name": "CVE-2022-49438",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49438"
},
{
"name": "CVE-2022-49440",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49440"
},
{
"name": "CVE-2022-49441",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49441"
},
{
"name": "CVE-2022-49442",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49442"
},
{
"name": "CVE-2022-49443",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49443"
},
{
"name": "CVE-2022-49444",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49444"
},
{
"name": "CVE-2022-49445",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49445"
},
{
"name": "CVE-2022-49447",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49447"
},
{
"name": "CVE-2022-49448",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49448"
},
{
"name": "CVE-2022-49449",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49449"
},
{
"name": "CVE-2022-49451",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49451"
},
{
"name": "CVE-2022-49453",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49453"
},
{
"name": "CVE-2022-49455",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49455"
},
{
"name": "CVE-2022-49459",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49459"
},
{
"name": "CVE-2022-49460",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49460"
},
{
"name": "CVE-2022-49462",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49462"
},
{
"name": "CVE-2022-49463",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49463"
},
{
"name": "CVE-2022-49466",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49466"
},
{
"name": "CVE-2022-49467",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49467"
},
{
"name": "CVE-2022-49468",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49468"
},
{
"name": "CVE-2022-49472",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49472"
},
{
"name": "CVE-2022-49473",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49473"
},
{
"name": "CVE-2022-49474",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49474"
},
{
"name": "CVE-2022-49475",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49475"
},
{
"name": "CVE-2022-49477",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49477"
},
{
"name": "CVE-2022-49478",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49478"
},
{
"name": "CVE-2022-49480",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49480"
},
{
"name": "CVE-2022-49481",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49481"
},
{
"name": "CVE-2022-49482",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49482"
},
{
"name": "CVE-2022-49486",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49486"
},
{
"name": "CVE-2022-49487",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49487"
},
{
"name": "CVE-2022-49488",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49488"
},
{
"name": "CVE-2022-49489",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49489"
},
{
"name": "CVE-2022-49491",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49491"
},
{
"name": "CVE-2022-49492",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49492"
},
{
"name": "CVE-2022-49493",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49493"
},
{
"name": "CVE-2022-49494",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49494"
},
{
"name": "CVE-2022-49495",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49495"
},
{
"name": "CVE-2022-49498",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49498"
},
{
"name": "CVE-2022-49501",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49501"
},
{
"name": "CVE-2022-49502",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49502"
},
{
"name": "CVE-2022-49503",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49503"
},
{
"name": "CVE-2022-49504",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49504"
},
{
"name": "CVE-2022-49505",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49505"
},
{
"name": "CVE-2022-49506",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49506"
},
{
"name": "CVE-2022-49507",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49507"
},
{
"name": "CVE-2022-49508",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49508"
},
{
"name": "CVE-2022-49509",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49509"
},
{
"name": "CVE-2022-49512",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49512"
},
{
"name": "CVE-2022-49514",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49514"
},
{
"name": "CVE-2022-49515",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49515"
},
{
"name": "CVE-2022-49517",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49517"
},
{
"name": "CVE-2022-49519",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49519"
},
{
"name": "CVE-2022-49520",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49520"
},
{
"name": "CVE-2022-49521",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49521"
},
{
"name": "CVE-2022-49522",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49522"
},
{
"name": "CVE-2022-49523",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49523"
},
{
"name": "CVE-2022-49524",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49524"
},
{
"name": "CVE-2022-49525",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49525"
},
{
"name": "CVE-2022-49526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49526"
},
{
"name": "CVE-2022-49527",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49527"
},
{
"name": "CVE-2022-49532",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49532"
},
{
"name": "CVE-2022-49534",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49534"
},
{
"name": "CVE-2022-49535",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49535"
},
{
"name": "CVE-2022-49536",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49536"
},
{
"name": "CVE-2022-49537",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49537"
},
{
"name": "CVE-2022-49541",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49541"
},
{
"name": "CVE-2022-49542",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49542"
},
{
"name": "CVE-2022-49544",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49544"
},
{
"name": "CVE-2022-49545",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49545"
},
{
"name": "CVE-2022-49546",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49546"
},
{
"name": "CVE-2022-49549",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49549"
},
{
"name": "CVE-2022-49551",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49551"
},
{
"name": "CVE-2022-49555",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49555"
},
{
"name": "CVE-2022-49556",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49556"
},
{
"name": "CVE-2022-49559",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49559"
},
{
"name": "CVE-2022-49562",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49562"
},
{
"name": "CVE-2022-49563",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49563"
},
{
"name": "CVE-2022-49564",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49564"
},
{
"name": "CVE-2022-49566",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49566"
},
{
"name": "CVE-2022-49568",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49568"
},
{
"name": "CVE-2022-49569",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49569"
},
{
"name": "CVE-2022-49570",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49570"
},
{
"name": "CVE-2022-49579",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49579"
},
{
"name": "CVE-2022-49581",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49581"
},
{
"name": "CVE-2022-49583",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49583"
},
{
"name": "CVE-2022-49584",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49584"
},
{
"name": "CVE-2022-49591",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49591"
},
{
"name": "CVE-2022-49592",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49592"
},
{
"name": "CVE-2022-49603",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49603"
},
{
"name": "CVE-2022-49605",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49605"
},
{
"name": "CVE-2022-49606",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49606"
},
{
"name": "CVE-2022-49607",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49607"
},
{
"name": "CVE-2022-49609",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49609"
},
{
"name": "CVE-2022-49610",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49610"
},
{
"name": "CVE-2022-49611",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49611"
},
{
"name": "CVE-2022-49613",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49613"
},
{
"name": "CVE-2022-49615",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49615"
},
{
"name": "CVE-2022-49616",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49616"
},
{
"name": "CVE-2022-49617",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49617"
},
{
"name": "CVE-2022-49618",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49618"
},
{
"name": "CVE-2022-49621",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49621"
},
{
"name": "CVE-2022-49623",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49623"
},
{
"name": "CVE-2022-49625",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49625"
},
{
"name": "CVE-2022-49627",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49627"
},
{
"name": "CVE-2022-49628",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49628"
},
{
"name": "CVE-2022-49631",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49631"
},
{
"name": "CVE-2022-49634",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49634"
},
{
"name": "CVE-2022-49640",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49640"
},
{
"name": "CVE-2022-49641",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49641"
},
{
"name": "CVE-2022-49642",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49642"
},
{
"name": "CVE-2022-49643",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49643"
},
{
"name": "CVE-2022-49644",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49644"
},
{
"name": "CVE-2022-49645",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49645"
},
{
"name": "CVE-2022-49646",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49646"
},
{
"name": "CVE-2022-49647",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49647"
},
{
"name": "CVE-2022-49648",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49648"
},
{
"name": "CVE-2022-49649",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49649"
},
{
"name": "CVE-2022-49652",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49652"
},
{
"name": "CVE-2022-49653",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49653"
},
{
"name": "CVE-2022-49656",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49656"
},
{
"name": "CVE-2022-49657",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49657"
},
{
"name": "CVE-2022-49663",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49663"
},
{
"name": "CVE-2022-49665",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49665"
},
{
"name": "CVE-2022-49667",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49667"
},
{
"name": "CVE-2022-49668",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49668"
},
{
"name": "CVE-2022-49670",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49670"
},
{
"name": "CVE-2022-49671",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49671"
},
{
"name": "CVE-2022-49672",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49672"
},
{
"name": "CVE-2022-49673",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49673"
},
{
"name": "CVE-2022-49674",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49674"
},
{
"name": "CVE-2022-49675",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49675"
},
{
"name": "CVE-2022-49676",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49676"
},
{
"name": "CVE-2022-49677",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49677"
},
{
"name": "CVE-2022-49678",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49678"
},
{
"name": "CVE-2022-49679",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49679"
},
{
"name": "CVE-2022-49680",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49680"
},
{
"name": "CVE-2022-49683",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49683"
},
{
"name": "CVE-2022-49685",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49685"
},
{
"name": "CVE-2022-49687",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49687"
},
{
"name": "CVE-2022-49688",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49688"
},
{
"name": "CVE-2022-49693",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49693"
},
{
"name": "CVE-2022-49695",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49695"
},
{
"name": "CVE-2022-49699",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49699"
},
{
"name": "CVE-2022-49700",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49700"
},
{
"name": "CVE-2022-49701",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49701"
},
{
"name": "CVE-2022-49703",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49703"
},
{
"name": "CVE-2022-49704",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49704"
},
{
"name": "CVE-2022-49705",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49705"
},
{
"name": "CVE-2022-49707",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49707"
},
{
"name": "CVE-2022-49708",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49708"
},
{
"name": "CVE-2022-49710",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49710"
},
{
"name": "CVE-2022-49711",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49711"
},
{
"name": "CVE-2022-49712",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49712"
},
{
"name": "CVE-2022-49713",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49713"
},
{
"name": "CVE-2022-49714",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49714"
},
{
"name": "CVE-2022-49715",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49715"
},
{
"name": "CVE-2022-49716",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49716"
},
{
"name": "CVE-2022-49719",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49719"
},
{
"name": "CVE-2022-49720",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49720"
},
{
"name": "CVE-2022-49721",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49721"
},
{
"name": "CVE-2022-49722",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49722"
},
{
"name": "CVE-2022-49723",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49723"
},
{
"name": "CVE-2022-49724",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49724"
},
{
"name": "CVE-2022-49725",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49725"
},
{
"name": "CVE-2022-49726",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49726"
},
{
"name": "CVE-2022-49729",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49729"
},
{
"name": "CVE-2022-49730",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49730"
},
{
"name": "CVE-2022-49731",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49731"
},
{
"name": "CVE-2022-49733",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49733"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2025-21772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21772"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2024-58013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58013"
},
{
"name": "CVE-2024-58052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58052"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2025-21703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21703"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2025-21762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21762"
},
{
"name": "CVE-2025-21763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21763"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2025-21766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21766"
},
{
"name": "CVE-2025-21776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21776"
},
{
"name": "CVE-2025-21782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21782"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2025-21821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21821"
},
{
"name": "CVE-2021-4454",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4454"
},
{
"name": "CVE-2022-49053",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49053"
},
{
"name": "CVE-2022-49056",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49056"
},
{
"name": "CVE-2022-49057",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49057"
},
{
"name": "CVE-2022-49062",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49062"
},
{
"name": "CVE-2022-49064",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49064"
},
{
"name": "CVE-2022-49070",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49070"
},
{
"name": "CVE-2022-49071",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49071"
},
{
"name": "CVE-2022-49075",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49075"
},
{
"name": "CVE-2022-49123",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49123"
},
{
"name": "CVE-2022-49125",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49125"
},
{
"name": "CVE-2022-49133",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49133"
},
{
"name": "CVE-2022-49136",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49136"
},
{
"name": "CVE-2022-49138",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49138"
},
{
"name": "CVE-2022-49139",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49139"
},
{
"name": "CVE-2022-49144",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49144"
},
{
"name": "CVE-2022-49183",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49183"
},
{
"name": "CVE-2022-49192",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49192"
},
{
"name": "CVE-2022-49202",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49202"
},
{
"name": "CVE-2022-49203",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49203"
},
{
"name": "CVE-2022-49204",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49204"
},
{
"name": "CVE-2022-49205",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49205"
},
{
"name": "CVE-2022-49207",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49207"
},
{
"name": "CVE-2022-49209",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49209"
},
{
"name": "CVE-2022-49215",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49215"
},
{
"name": "CVE-2022-49219",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49219"
},
{
"name": "CVE-2022-49225",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49225"
},
{
"name": "CVE-2022-49228",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49228"
},
{
"name": "CVE-2022-49230",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49230"
},
{
"name": "CVE-2022-49233",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49233"
},
{
"name": "CVE-2022-49237",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49237"
},
{
"name": "CVE-2022-49238",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49238"
},
{
"name": "CVE-2022-49293",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49293"
},
{
"name": "CVE-2022-49296",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49296"
},
{
"name": "CVE-2022-49306",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49306"
},
{
"name": "CVE-2022-49325",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49325"
},
{
"name": "CVE-2022-49329",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49329"
},
{
"name": "CVE-2022-49330",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49330"
},
{
"name": "CVE-2022-49333",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49333"
},
{
"name": "CVE-2022-49338",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49338"
},
{
"name": "CVE-2022-49353",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49353"
},
{
"name": "CVE-2022-49359",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49359"
},
{
"name": "CVE-2022-49362",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49362"
},
{
"name": "CVE-2022-49365",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49365"
},
{
"name": "CVE-2022-49390",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49390"
},
{
"name": "CVE-2022-49406",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49406"
},
{
"name": "CVE-2022-49419",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49419"
},
{
"name": "CVE-2022-49436",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49436"
},
{
"name": "CVE-2022-49446",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49446"
},
{
"name": "CVE-2022-49458",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49458"
},
{
"name": "CVE-2022-49465",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49465"
},
{
"name": "CVE-2022-49470",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49470"
},
{
"name": "CVE-2022-49476",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49476"
},
{
"name": "CVE-2022-49479",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49479"
},
{
"name": "CVE-2022-49483",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49483"
},
{
"name": "CVE-2022-49484",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49484"
},
{
"name": "CVE-2022-49485",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49485"
},
{
"name": "CVE-2022-49497",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49497"
},
{
"name": "CVE-2022-49499",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49499"
},
{
"name": "CVE-2022-49510",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49510"
},
{
"name": "CVE-2022-49511",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49511"
},
{
"name": "CVE-2022-49516",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49516"
},
{
"name": "CVE-2022-49518",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49518"
},
{
"name": "CVE-2022-49529",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49529"
},
{
"name": "CVE-2022-49530",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49530"
},
{
"name": "CVE-2022-49533",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49533"
},
{
"name": "CVE-2022-49538",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49538"
},
{
"name": "CVE-2022-49543",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49543"
},
{
"name": "CVE-2022-49548",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49548"
},
{
"name": "CVE-2022-49552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49552"
},
{
"name": "CVE-2022-49560",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49560"
},
{
"name": "CVE-2022-49565",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49565"
},
{
"name": "CVE-2022-49624",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49624"
},
{
"name": "CVE-2022-49635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49635"
},
{
"name": "CVE-2022-49638",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49638"
},
{
"name": "CVE-2022-49650",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49650"
},
{
"name": "CVE-2022-49655",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49655"
},
{
"name": "CVE-2022-49658",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49658"
},
{
"name": "CVE-2022-49686",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49686"
},
{
"name": "CVE-2022-49694",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49694"
},
{
"name": "CVE-2022-49697",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49697"
},
{
"name": "CVE-2022-49732",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49732"
},
{
"name": "CVE-2022-49739",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49739"
},
{
"name": "CVE-2022-49746",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49746"
},
{
"name": "CVE-2022-49748",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49748"
},
{
"name": "CVE-2022-49751",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49751"
},
{
"name": "CVE-2022-49753",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49753"
},
{
"name": "CVE-2022-49755",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49755"
},
{
"name": "CVE-2022-49759",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49759"
},
{
"name": "CVE-2023-52930",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52930"
},
{
"name": "CVE-2023-52933",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52933"
},
{
"name": "CVE-2023-52935",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52935"
},
{
"name": "CVE-2023-52939",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52939"
},
{
"name": "CVE-2023-52941",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52941"
},
{
"name": "CVE-2023-52973",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52973"
},
{
"name": "CVE-2023-52974",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52974"
},
{
"name": "CVE-2023-52975",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52975"
},
{
"name": "CVE-2023-52976",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52976"
},
{
"name": "CVE-2023-52979",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52979"
},
{
"name": "CVE-2023-52983",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52983"
},
{
"name": "CVE-2023-52984",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52984"
},
{
"name": "CVE-2023-52988",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52988"
},
{
"name": "CVE-2023-52989",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52989"
},
{
"name": "CVE-2023-52992",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52992"
},
{
"name": "CVE-2023-52993",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52993"
},
{
"name": "CVE-2023-53000",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53000"
},
{
"name": "CVE-2023-53005",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53005"
},
{
"name": "CVE-2023-53006",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53006"
},
{
"name": "CVE-2023-53007",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53007"
},
{
"name": "CVE-2023-53008",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53008"
},
{
"name": "CVE-2023-53010",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53010"
},
{
"name": "CVE-2023-53015",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53015"
},
{
"name": "CVE-2023-53016",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53016"
},
{
"name": "CVE-2023-53019",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53019"
},
{
"name": "CVE-2023-53023",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53023"
},
{
"name": "CVE-2023-53024",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53024"
},
{
"name": "CVE-2023-53025",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53025"
},
{
"name": "CVE-2023-53026",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53026"
},
{
"name": "CVE-2023-53028",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53028"
},
{
"name": "CVE-2023-53029",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53029"
},
{
"name": "CVE-2023-53030",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53030"
},
{
"name": "CVE-2023-53033",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53033"
},
{
"name": "CVE-2025-21693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21693"
},
{
"name": "CVE-2025-21759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21759"
},
{
"name": "CVE-2025-21831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21831"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2025-21848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21848"
},
{
"name": "CVE-2025-21855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21855"
},
{
"name": "CVE-2025-21858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21858"
},
{
"name": "CVE-2025-21865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21865"
},
{
"name": "CVE-2025-21871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21871"
},
{
"name": "CVE-2025-21877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21877"
},
{
"name": "CVE-2025-21891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21891"
},
{
"name": "CVE-2025-21916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21916"
},
{
"name": "CVE-2025-21922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21922"
},
{
"name": "CVE-2025-21934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21934"
},
{
"name": "CVE-2025-21935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21935"
},
{
"name": "CVE-2025-21993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21993"
},
{
"name": "CVE-2025-21996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21996"
},
{
"name": "CVE-2025-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22007"
},
{
"name": "CVE-2022-49046",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49046"
},
{
"name": "CVE-2022-49191",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49191"
},
{
"name": "CVE-2022-49220",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49220"
},
{
"name": "CVE-2022-49344",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49344"
},
{
"name": "CVE-2022-49372",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49372"
},
{
"name": "CVE-2022-49388",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49388"
},
{
"name": "CVE-2022-49395",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49395"
},
{
"name": "CVE-2022-49513",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49513"
},
{
"name": "CVE-2022-49578",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49578"
},
{
"name": "CVE-2022-49589",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49589"
},
{
"name": "CVE-2022-49619",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49619"
},
{
"name": "CVE-2022-49620",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49620"
},
{
"name": "CVE-2022-49727",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49727"
},
{
"name": "CVE-2022-49740",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49740"
},
{
"name": "CVE-2023-52997",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52997"
},
{
"name": "CVE-2023-53031",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53031"
},
{
"name": "CVE-2025-21969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21969"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0336",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-04-18T00:00:00.000000"
}
],
"risks": [
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de SUSE. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de SUSE",
"vendor_advisories": [
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1225-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251225-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1232-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251232-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1248-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251248-1"
},
{
"published_at": "2025-04-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1276-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251276-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1259-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251259-1"
},
{
"published_at": "2025-04-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1262-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251262-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1241-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251241-1"
},
{
"published_at": "2025-04-13",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1207-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251207-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1236-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251236-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1260-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251260-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1213-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251213-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1252-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251252-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1238-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251238-1"
},
{
"published_at": "2025-04-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1275-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251275-1"
},
{
"published_at": "2025-04-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1278-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251278-1"
},
{
"published_at": "2025-04-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1263-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251263-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1254-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251254-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1257-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251257-1"
},
{
"published_at": "2025-04-13",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1214-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251214-1"
},
{
"published_at": "2025-04-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1293-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251293-1"
},
{
"published_at": "2025-04-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:1231-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20251231-1"
}
]
}
BDU:2026-03682 (CVE-2022-49513)
Vulnerability from fstec – Published: 2026-03-25 – Updated: 2026-03-25 – View on bdu.fstec.ru Fixed- CWE-371 - Проблемы управления состоянием
| URL |
|---|
| https://git.kernel.org/stable/c/1e32083f327184b6226ce320ef30085ce785ea4e |
| https://git.kernel.org/stable/c/a1964688582d26af1328e19b658933659fb54337 |
| https://www.cve.org/CVERecord?id=CVE-2022-49513 |
| https://lore.kernel.org/linux-cve-announce/2025022609-CVE-2022-49513-f147@gregkh/ |
| https://git.kernel.org/linus/a85ee6401a47ae3fc64ba506cacb3e7873823c65 |
| https://kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.91 |
| https://kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.3 |
| https://access.redhat.com/security/cve/cve-2022-49513 |
| https://ubuntu.com/security/CVE-2022-49513 |
{
"CVSS 2.0": "AV:L/AC:L/Au:S/C:N/I:N/A:C",
"CVSS 3.0": "AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"CVSS 4.0": null,
"remediation_\u0418\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440": null,
"remediation_\u041d\u0430\u0438\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435": null,
"\u0412\u0435\u043d\u0434\u043e\u0440 \u041f\u041e": "Canonical Ltd., Red Hat, Inc., \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f",
"\u0412\u0435\u0440\u0441\u0438\u044f \u041f\u041e": "16.04 LTS (Ubuntu), 18.04 LTS (Ubuntu), 8 (Red Hat Enterprise Linux), 20.04 LTS (Ubuntu), 22.04 LTS (Ubuntu), 9 (Red Hat Enterprise Linux), \u043e\u0442 5.16 \u0434\u043e 5.18.2 \u0432\u043a\u043b\u044e\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e (Linux), \u043e\u0442 4.6 \u0434\u043e 5.15.90 \u0432\u043a\u043b\u044e\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e (Linux)",
"\u0412\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0435 \u043c\u0435\u0440\u044b \u043f\u043e \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u044e": "\u0412 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043e\u0442\u0441\u0443\u0442\u0441\u0442\u0432\u0438\u044f \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0439 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u043e\u0442 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0443\u0435\u0442\u0441\u044f \u043f\u0440\u0438\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0442\u044c\u0441\u044f \"\u0420\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0439 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0439 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c LINUX\", \u0438\u0437\u043b\u043e\u0436\u0435\u043d\u043d\u044b\u0445 \u0432 \u043c\u0435\u0442\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0435 \u0424\u0421\u0422\u042d\u041a \u0420\u043e\u0441\u0441\u0438\u0438, \u0443\u0442\u0432\u0435\u0440\u0436\u0434\u0451\u043d\u043d\u043e\u043c 25 \u0434\u0435\u043a\u0430\u0431\u0440\u044f 2022 \u0433\u043e\u0434\u0430.\n\n\u0418\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0439:\n\u0414\u043b\u044f Linux:\nhttps://git.kernel.org/stable/c/1e32083f327184b6226ce320ef30085ce785ea4e\nhttps://git.kernel.org/stable/c/a1964688582d26af1328e19b658933659fb54337\nhttps://git.kernel.org/linus/a85ee6401a47ae3fc64ba506cacb3e7873823c65\n\n\u0414\u043b\u044f \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u044b\u0445 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u0432 Red Hat Inc.:\nhttps://access.redhat.com/security/cve/cve-2022-49513\n\n\u0414\u043b\u044f \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u044b\u0445 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u0432 Ubuntu:\nhttps://ubuntu.com/security/CVE-2022-49513",
"\u0414\u0430\u0442\u0430 \u0432\u044b\u044f\u0432\u043b\u0435\u043d\u0438\u044f": "13.04.2022",
"\u0414\u0430\u0442\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0433\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f": "25.03.2026",
"\u0414\u0430\u0442\u0430 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438": "25.03.2026",
"\u0418\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440": "BDU:2026-03682",
"\u0418\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440\u044b \u0434\u0440\u0443\u0433\u0438\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0439 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "CVE-2022-49513, RHSA-2023:2458, RHSA-2023:2951",
"\u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u043e\u0431 \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0430",
"\u041a\u043b\u0430\u0441\u0441 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u043a\u043e\u0434\u0430",
"\u041d\u0430\u0437\u0432\u0430\u043d\u0438\u0435 \u041f\u041e": "Ubuntu, Red Hat Enterprise Linux, Linux",
"\u041d\u0430\u0438\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435 \u041e\u0421 \u0438 \u0442\u0438\u043f \u0430\u043f\u043f\u0430\u0440\u0430\u0442\u043d\u043e\u0439 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b": "Canonical Ltd. Ubuntu 16.04 LTS , Canonical Ltd. Ubuntu 18.04 LTS , Red Hat, Inc. Red Hat Enterprise Linux 8 , Canonical Ltd. Ubuntu 20.04 LTS , Canonical Ltd. Ubuntu 22.04 LTS , Red Hat, Inc. Red Hat Enterprise Linux 9 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux \u043e\u0442 5.16 \u0434\u043e 5.18.2 \u0432\u043a\u043b\u044e\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux \u043e\u0442 4.6 \u0434\u043e 5.15.90 \u0432\u043a\u043b\u044e\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e ",
"\u041d\u0430\u0438\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u0438 free_policy_dbs_info() \u043c\u043e\u0434\u0443\u043b\u044f drivers/cpufreq/cpufreq_governor.c \u0434\u0440\u0430\u0439\u0432\u0435\u0440\u0430 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0447\u0430\u0441\u0442\u043e\u0442\u044b \u0426\u041f \u044f\u0434\u0440\u0430 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b Linux, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u043d\u0430\u0440\u0443\u0448\u0438\u0442\u0435\u043b\u044e \u0432\u044b\u0437\u0432\u0430\u0442\u044c \u043e\u0442\u043a\u0430\u0437 \u0432 \u043e\u0431\u0441\u043b\u0443\u0436\u0438\u0432\u0430\u043d\u0438\u0438",
"\u041d\u0430\u043b\u0438\u0447\u0438\u0435 \u044d\u043a\u0441\u043f\u043b\u043e\u0439\u0442\u0430": "\u0414\u0430\u043d\u043d\u044b\u0435 \u0443\u0442\u043e\u0447\u043d\u044f\u044e\u0442\u0441\u044f",
"\u041e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043e\u0448\u0438\u0431\u043a\u0438 CWE": "\u041f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0435\u043c (CWE-371)",
"\u041e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u0438 free_policy_dbs_info() \u043c\u043e\u0434\u0443\u043b\u044f drivers/cpufreq/cpufreq_governor.c \u0434\u0440\u0430\u0439\u0432\u0435\u0440\u0430 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0447\u0430\u0441\u0442\u043e\u0442\u044b \u0426\u041f \u044f\u0434\u0440\u0430 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b Linux \u0441\u0432\u044f\u0437\u0430\u043d\u0430 \u0441 \u043e\u0448\u0438\u0431\u043a\u0430\u043c\u0438 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0435\u043c. \u042d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442\u044c \u043d\u0430\u0440\u0443\u0448\u0438\u0442\u0435\u043b\u044e \u0432\u044b\u0437\u0432\u0430\u0442\u044c \u043e\u0442\u043a\u0430\u0437 \u0432 \u043e\u0431\u0441\u043b\u0443\u0436\u0438\u0432\u0430\u043d\u0438\u0438",
"\u041f\u043e\u0441\u043b\u0435\u0434\u0441\u0442\u0432\u0438\u044f \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": null,
"\u041f\u0440\u043e\u0447\u0430\u044f \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f": null,
"\u0421\u0432\u044f\u0437\u044c \u0441 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442\u0430\u043c\u0438 \u0418\u0411": "\u0414\u0430\u043d\u043d\u044b\u0435 \u0443\u0442\u043e\u0447\u043d\u044f\u044e\u0442\u0441\u044f",
"\u0421\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u041e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u0430",
"\u0421\u043f\u043e\u0441\u043e\u0431 \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u044f": "\u041e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f",
"\u0421\u043f\u043e\u0441\u043e\u0431 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438": "\u041c\u0430\u043d\u0438\u043f\u0443\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0441\u0440\u043e\u043a\u0430\u043c\u0438 \u0438 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0435\u043c",
"\u0421\u0441\u044b\u043b\u043a\u0438 \u043d\u0430 \u0438\u0441\u0442\u043e\u0447\u043d\u0438\u043a\u0438": "https://git.kernel.org/stable/c/1e32083f327184b6226ce320ef30085ce785ea4e\nhttps://git.kernel.org/stable/c/a1964688582d26af1328e19b658933659fb54337\nhttps://www.cve.org/CVERecord?id=CVE-2022-49513\nhttps://lore.kernel.org/linux-cve-announce/2025022609-CVE-2022-49513-f147@gregkh/\nhttps://git.kernel.org/linus/a85ee6401a47ae3fc64ba506cacb3e7873823c65\nhttps://kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.91\nhttps://kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.3\nhttps://access.redhat.com/security/cve/cve-2022-49513\nhttps://ubuntu.com/security/CVE-2022-49513",
"\u0421\u0442\u0430\u0442\u0443\u0441 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u041f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c",
"\u0422\u0438\u043f \u041f\u041e": "\u041e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430",
"\u0422\u0438\u043f \u043e\u0448\u0438\u0431\u043a\u0438 CWE": "CWE-371",
"\u0423\u0440\u043e\u0432\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0421\u0440\u0435\u0434\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 (\u0431\u0430\u0437\u043e\u0432\u0430\u044f \u043e\u0446\u0435\u043d\u043a\u0430 CVSS 2.0 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442 4,6)\n\u0421\u0440\u0435\u0434\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 (\u0431\u0430\u0437\u043e\u0432\u0430\u044f \u043e\u0446\u0435\u043d\u043a\u0430 CVSS 3.1 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442 5,5)"
}
FKIE_CVE-2022-49513
Vulnerability from fkie_nvd - Published: 2025-02-26 07:01 - Updated: 2026-06-17 05:18| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/1e32083f327184b6226ce320ef30085ce785ea4e | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/a1964688582d26af1328e19b658933659fb54337 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/a85ee6401a47ae3fc64ba506cacb3e7873823c65 | Patch |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/cpufreq/cpufreq_governor.c",
"drivers/cpufreq/cpufreq_governor.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "a1964688582d26af1328e19b658933659fb54337",
"status": "affected",
"version": "c4435630361d9bebf7154a0c842dc1fb7ae39c99",
"versionType": "git"
},
{
"lessThan": "1e32083f327184b6226ce320ef30085ce785ea4e",
"status": "affected",
"version": "c4435630361d9bebf7154a0c842dc1fb7ae39c99",
"versionType": "git"
},
{
"lessThan": "a85ee6401a47ae3fc64ba506cacb3e7873823c65",
"status": "affected",
"version": "c4435630361d9bebf7154a0c842dc1fb7ae39c99",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/cpufreq/cpufreq_governor.c",
"drivers/cpufreq/cpufreq_governor.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.6"
},
{
"lessThan": "4.6",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.91",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.18.*",
"status": "unaffected",
"version": "5.18.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E971D8DD-B809-44DF-A31F-1A124020CE28",
"versionEndExcluding": "5.15.91",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "98CD047E-3CA9-4A90-93B0-040784FAD016",
"versionEndExcluding": "5.18.3",
"versionStartIncluding": "5.16",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: governor: Use kobject release() method to free dbs_data\n\nThe struct dbs_data embeds a struct gov_attr_set and\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\na release() method and we can\u0027t use kfree() to free it directly,\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\nthe kobject::release() method. This fixes the calltrace like below:\n\n ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\n WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n Modules linked in:\n CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\n Hardware name: Marvell OcteonTX CN96XX board (DT)\n pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : debug_print_object+0xb8/0x100\n lr : debug_print_object+0xb8/0x100\n sp : ffff80001dfcf9a0\n x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\n x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\n x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\n x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\n x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\n x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\n x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\n x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\n x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\n Call trace:\n debug_print_object+0xb8/0x100\n __debug_check_no_obj_freed+0x1d0/0x25c\n debug_check_no_obj_freed+0x24/0xa0\n kfree+0x11c/0x440\n cpufreq_dbs_governor_exit+0xa8/0xac\n cpufreq_exit_governor+0x44/0x90\n cpufreq_set_policy+0x29c/0x570\n store_scaling_governor+0x110/0x154\n store+0xb0/0xe0\n sysfs_kf_write+0x58/0x84\n kernfs_fop_write_iter+0x12c/0x1c0\n new_sync_write+0xf0/0x18c\n vfs_write+0x1cc/0x220\n ksys_write+0x74/0x100\n __arm64_sys_write+0x28/0x3c\n invoke_syscall.constprop.0+0x58/0xf0\n do_el0_svc+0x70/0x170\n el0_svc+0x54/0x190\n el0t_64_sync_handler+0xa4/0x130\n el0t_64_sync+0x1a0/0x1a4\n irq event stamp: 189006\n hardirqs last enabled at (189005): [\u003cffff8000080849d0\u003e] finish_task_switch.isra.0+0xe0/0x2c0\n hardirqs last disabled at (189006): [\u003cffff8000090667a4\u003e] el1_dbg+0x24/0xa0\n softirqs last enabled at (188966): [\u003cffff8000080106d0\u003e] __do_softirq+0x4b0/0x6a0\n softirqs last disabled at (188957): [\u003cffff80000804a618\u003e] __irq_exit_rcu+0x108/0x1a4\n\n[ rjw: Because can be freed by the gov_attr_set_put() in\n cpufreq_dbs_governor_exit() now, it is also necessary to put the\n invocation of the governor -\u003eexit() callback into the new\n cpufreq_dbs_data_release() function. ]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: governor: Use el m\u00e9todo kobject release() para liberar dbs_data La estructura dbs_data incorpora una estructura gov_attr_set y la estructura gov_attr_set incorpora un kobject. Dado que cada kobject debe tener un m\u00e9todo release() y no podemos usar kfree() para liberarlo directamente, introduzca cpufreq_dbs_data_release() para liberar dbs_data a trav\u00e9s del m\u00e9todo kobject::release(). Esto corrige el seguimiento de llamadas como se muestra a continuaci\u00f3n: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4 [ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor -\u0026gt;exit() callback into the new cpufreq_dbs_data_release() function. ] "
}
],
"id": "CVE-2022-49513",
"lastModified": "2026-06-17T05:18:17.480",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-02-26T07:01:27.380",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1e32083f327184b6226ce320ef30085ce785ea4e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a1964688582d26af1328e19b658933659fb54337"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a85ee6401a47ae3fc64ba506cacb3e7873823c65"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-33XC-W6XP-76J4
Vulnerability from github – Published: 2025-10-21 12:31 – Updated: 2025-10-21 12:31In the Linux kernel, the following vulnerability has been resolved:
cpufreq: governor: Use kobject release() method to free dbs_data
The struct dbs_data embeds a struct gov_attr_set and the struct gov_attr_set embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreq_dbs_data_release() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4
[ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreq_dbs_data_release() function. ]
{
"affected": [],
"aliases": [
"CVE-2022-49513"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: governor: Use kobject release() method to free dbs_data\n\nThe struct dbs_data embeds a struct gov_attr_set and\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\na release() method and we can\u0027t use kfree() to free it directly,\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\nthe kobject::release() method. This fixes the calltrace like below:\n\n ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\n WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n Modules linked in:\n CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\n Hardware name: Marvell OcteonTX CN96XX board (DT)\n pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : debug_print_object+0xb8/0x100\n lr : debug_print_object+0xb8/0x100\n sp : ffff80001dfcf9a0\n x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\n x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\n x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\n x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\n x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\n x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\n x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\n x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\n x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\n Call trace:\n debug_print_object+0xb8/0x100\n __debug_check_no_obj_freed+0x1d0/0x25c\n debug_check_no_obj_freed+0x24/0xa0\n kfree+0x11c/0x440\n cpufreq_dbs_governor_exit+0xa8/0xac\n cpufreq_exit_governor+0x44/0x90\n cpufreq_set_policy+0x29c/0x570\n store_scaling_governor+0x110/0x154\n store+0xb0/0xe0\n sysfs_kf_write+0x58/0x84\n kernfs_fop_write_iter+0x12c/0x1c0\n new_sync_write+0xf0/0x18c\n vfs_write+0x1cc/0x220\n ksys_write+0x74/0x100\n __arm64_sys_write+0x28/0x3c\n invoke_syscall.constprop.0+0x58/0xf0\n do_el0_svc+0x70/0x170\n el0_svc+0x54/0x190\n el0t_64_sync_handler+0xa4/0x130\n el0t_64_sync+0x1a0/0x1a4\n irq event stamp: 189006\n hardirqs last enabled at (189005): [\u003cffff8000080849d0\u003e] finish_task_switch.isra.0+0xe0/0x2c0\n hardirqs last disabled at (189006): [\u003cffff8000090667a4\u003e] el1_dbg+0x24/0xa0\n softirqs last enabled at (188966): [\u003cffff8000080106d0\u003e] __do_softirq+0x4b0/0x6a0\n softirqs last disabled at (188957): [\u003cffff80000804a618\u003e] __irq_exit_rcu+0x108/0x1a4\n\n[ rjw: Because can be freed by the gov_attr_set_put() in\n cpufreq_dbs_governor_exit() now, it is also necessary to put the\n invocation of the governor -\u003eexit() callback into the new\n cpufreq_dbs_data_release() function. ]",
"id": "GHSA-33xc-w6xp-76j4",
"modified": "2025-10-21T12:31:26Z",
"published": "2025-10-21T12:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49513"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e32083f327184b6226ce320ef30085ce785ea4e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1964688582d26af1328e19b658933659fb54337"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a85ee6401a47ae3fc64ba506cacb3e7873823c65"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
oesa-2025-1317
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl
Hulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi]
Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi]
Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ==================================================================
The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held by ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can be concurrent.
ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach. ubi_detach is bug-free because it uses reference counting to prevent concurrency. However, uif_init and uif_close in ubi_attach may race with ubi_cdev_ioctl.
uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _____|___|_______ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_del
And uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _____|___|_______ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double free
The cause of this problem is that commit 714fb87e8bc0 make device "available" before it becomes accessible via sysfs. Therefore, we roll back the modification. We will fix the race condition between ubi device creation and udev by removing ubi_get_device in vol_attribute_show and dev_attribute_show.This avoids accessing uninitialized ubi_devices[ubi_num].
ubi_get_device is used to prevent devices from being deleted during sysfs execution. However, now kernfs ensures that devices will not be deleted before all reference counting are released. The key process is shown in the following stack.
device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain(CVE-2021-47634)
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix use-after-free in jffs2_clear_xattr_subsystem
When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then called in jffs2_build_filesystem() and then again in jffs2_do_fill_super().
Finally we can observe the following report: ================================================================== BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac Read of size 8 at addr ffff8881243384e0 by task mount/719
Call Trace: dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Allocated by task 719: kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...]
Freed by task 719: kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...]
The buggy address belongs to the object at ffff8881243384b8 which belongs to the cache jffs2_xattr_ref of size 48 The buggy address is located 40 bytes inside of 48-byte region [ffff8881243384b8, ffff8881243384e8) [...] ==================================================================
The triggering of the BUG is shown in the following stack:
jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- ERROR jffs2_clear_xattr_subsystem <--- free jffs2_clear_xattr_subsystem <--- free again
An error is returned in jffs2_do_mount_fs(). If the error is returned by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to be executed. If the error is returned by jffs2_build_filesystem(), the jffs2_clear_xattr_subsystem() also does not need to be executed again. So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root' to fix this UAF problem.(CVE-2021-47656)
In the Linux kernel, the following vulnerability has been resolved:
mm: fix unexpected zeroed page mapping with zram swap
Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly.
CPU A CPU B
do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the zero data to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed data
The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't increase the refcount of swap slot at copy_mm so it couldn't catch up whether it's safe or not to discard data from backing device. In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock. Thus, this patch gets rid of the swap_slot_free_notify function. With this patch, CPU A will see correct data.
CPU A CPU B
do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU B
The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space. However, most of cases of zram uses no readahead and do_swap_page is followed by swap_free so it will free the compressed form from in zram quickly.(CVE-2022-49052)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix a race in rxrpc_exit_net()
Current code can lead to the following race:
CPU0 CPU1
rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->live)
rxnet->live = false; del_timer_sync(&rxnet->peer_keepalive_timer);
timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);
cancel_work_sync(&rxnet->peer_keepalive_work);
rxrpc_exit_net() exits while peer_keepalive_timer is still armed, leading to use-after-free.
syzbot report was:
ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0 WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Modules linked in: CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0 R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __debug_check_no_obj_freed lib/debugobjects.c:992 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176 ops_free_list net/core/net_namespace.c:174 [inline] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 </TASK>(CVE-2022-49087)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()
[ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020 [ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1 [ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018 [ 12.356356] Call Trace: [ 12.358821] dump_stack_lvl+0x34/0x44 [ 12.362514] check_preemption_disabled+0xd9/0xe0 [ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx] [ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40 [ 12.384284] local_pci_probe+0x42/0x80 [ 12.390162] ? pci_match_device+0xd7/0x110 [ 12.396366] pci_device_probe+0xfd/0x1b0 [ 12.402372] really_probe+0x1e7/0x3e0 [ 12.408114] __driver_probe_device+0xfe/0x180 [ 12.414544] driver_probe_device+0x1e/0x90 [ 12.420685] __driver_attach+0xc0/0x1c0 [ 12.426536] ? __device_attach_driver+0xe0/0xe0 [ 12.433061] ? __device_attach_driver+0xe0/0xe0 [ 12.439538] bus_for_each_dev+0x78/0xc0 [ 12.445294] bus_add_driver+0x12b/0x1e0 [ 12.451021] driver_register+0x8f/0xe0 [ 12.456631] ? 0xffffffffc07bc000 [ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx] [ 12.468776] do_one_initcall+0x44/0x200 [ 12.474401] ? load_module+0xad3/0xba0 [ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410 [ 12.486268] do_init_module+0x5c/0x280 [ 12.491730] __do_sys_init_module+0x12e/0x1b0 [ 12.497785] do_syscall_64+0x3b/0x90 [ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 12.509764] RIP: 0033:0x7f554f73ab2e(CVE-2022-49155)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction
AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA: firewire-lib: Add support for deferred transaction") while 'deferrable' flag can be uninitialized for non-control/notify AV/C transactions. UBSAN reports it:
kernel: ================================================================================ kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9 kernel: load of value 158 is not a valid value for type '_Bool' kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu kernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019 kernel: Call Trace: kernel: <IRQ> kernel: show_stack+0x52/0x58 kernel: dump_stack_lvl+0x4a/0x5f kernel: dump_stack+0x10/0x12 kernel: ubsan_epilogue+0x9/0x45 kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49 kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib] kernel: fcp_response+0x28/0x30 [snd_firewire_lib] kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core] kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core] kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci] kernel: tasklet_action_common.constprop.0+0xea/0xf0 kernel: tasklet_action+0x22/0x30 kernel: __do_softirq+0xd9/0x2e3 kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0 kernel: do_softirq+0x75/0xa0 kernel: </IRQ> kernel: <TASK> kernel: __local_bh_enable_ip+0x50/0x60 kernel: irq_forced_thread_fn+0x7e/0x90 kernel: irq_thread+0xba/0x190 kernel: ? irq_thread_fn+0x60/0x60 kernel: kthread+0x11e/0x140 kernel: ? irq_thread_check_affinity+0xf0/0xf0 kernel: ? set_kthread_struct+0x50/0x50 kernel: ret_from_fork+0x22/0x30 kernel: </TASK> kernel: ================================================================================
This commit fixes the bug. The bug has no disadvantage for the non- control/notify AV/C transactions since the flag has an effect for AV/C response with INTERIM (0x0f) status which is not used for the transactions in AV/C general specification.(CVE-2022-49248)
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_scan_medium
If an error is returned in jffs2_scan_eraseblock() and some memory has been added to the jffs2_summary *s, we can observe the following kmemleak report:
unreferenced object 0xffff88812b889c40 (size 64): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P. 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................ backtrace: [<ffffffffae93a3a3>] __kmalloc+0x613/0x910 [<ffffffffaf423b9c>] jffs2_sum_add_dirent_mem+0x5c/0xa0 [<ffffffffb0f3afa8>] jffs2_scan_medium.cold+0x36e5/0x4794 [<ffffffffb0f3dbe1>] jffs2_do_mount_fs.cold+0xa7/0x2267 [<ffffffffaf40acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffaf40c00a>] jffs2_fill_super+0x2ea/0x4c0 [<ffffffffb0315d64>] mtd_get_sb+0x254/0x400 [<ffffffffb0315f5f>] mtd_get_sb_by_nr+0x4f/0xd0 [<ffffffffb0316478>] get_tree_mtd+0x498/0x840 [<ffffffffaf40bd15>] jffs2_get_tree+0x25/0x30 [<ffffffffae9f358d>] vfs_get_tree+0x8d/0x2e0 [<ffffffffaea7a98f>] path_mount+0x50f/0x1e50 [<ffffffffaea7c3d7>] do_mount+0x107/0x130 [<ffffffffaea7c5c5>] __se_sys_mount+0x1c5/0x2f0 [<ffffffffaea7c917>] __x64_sys_mount+0xc7/0x160 [<ffffffffb10142f5>] do_syscall_64+0x45/0x70 unreferenced object 0xffff888114b54840 (size 32): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u.............. 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423b04>] jffs2_sum_add_inode_mem+0x54/0x90 [<ffffffffb0f3bd44>] jffs2_scan_medium.cold+0x4481/0x4794 [...] unreferenced object 0xffff888114b57280 (size 32): comm "mount", pid 692, jiffies 4294838393 (age 34.357s) hex dump (first 32 bytes): 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l............. 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423c34>] jffs2_sum_add_xattr_mem+0x54/0x90 [<ffffffffb0f3a24f>] jffs2_scan_medium.cold+0x298c/0x4794 [...] unreferenced object 0xffff8881116cd510 (size 16): comm "mount", pid 692, jiffies 4294838395 (age 34.355s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423cc4>] jffs2_sum_add_xref_mem+0x54/0x90 [<ffffffffb0f3b2e3>] jffs2_scan_medium.cold+0x3a20/0x4794 [...]
Therefore, we should call jffs2_sum_reset_collected(s) on exit to release the memory added in s. In addition, a new tag "out_buf" is added to prevent the NULL pointer reference caused by s being NULL. (thanks to Zhang Yi for this analysis)(CVE-2022-49276)
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_mount_fs
If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error, we can observe the following kmemleak report:
unreferenced object 0xffff88811b25a640 (size 64): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) hex dump (first 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: [<ffffffffa493be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffa5423a06>] jffs2_sum_init+0x86/0x130 [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0 [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0 [...] unreferenced object 0xffff88812c760000 (size 65536): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [<ffffffffa493a449>] __kmalloc+0x6b9/0x910 [<ffffffffa5423a57>] jffs2_sum_init+0xd7/0x130 [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0 [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0 [...]
This is because the resources allocated in jffs2_sum_init() are not released. Call jffs2_sum_exit() to release these resources to solve the problem.(CVE-2022-49277)
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()
There is a deadlock in rtllib_beacons_stop(), which is shown below:
(Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ...
We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, rtllib_beacons_stop() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.(CVE-2022-49315)
In the Linux kernel, the following vulnerability has been resolved:
mips: cpc: Fix refcount leak in mips_cpc_default_phys_base
Add the missing of_node_put() to release the refcount incremented by of_find_compatible_node().(CVE-2022-49324)
In the Linux kernel, the following vulnerability has been resolved:
nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths.(CVE-2022-49331)
In the Linux kernel, the following vulnerability has been resolved:
rtc: mt6397: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.(CVE-2022-49375)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix race condition between ext4_write and ext4_convert_inline_data
Hulk Robot reported a BUG_ON: ================================================================== EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters kernel BUG at fs/ext4/ext4_jbd2.c:53! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline] RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116 [...] Call Trace: ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795 generic_perform_write+0x279/0x3c0 mm/filemap.c:3344 ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270 ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520 do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732 do_iter_write+0x107/0x430 fs/read_write.c:861 vfs_writev fs/read_write.c:934 [inline] do_pwritev+0x1e5/0x380 fs/read_write.c:1031 [...] ==================================================================
Above issue may happen as follows: cpu1 cpu2 ____|___ dopwritev vfs_writev do_iter_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_destroy_inline_data_nolock clear EXT4_STATE_MAY_INLINE_DATA ext4_map_blocks ext4_ext_map_blocks ext4_mb_new_blocks ext4_mb_regular_allocator ext4_mb_good_group_nolock ext4_mb_init_group ext4_mb_init_cache ext4_mb_generate_buddy --> error ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_restore_inline_data set EXT4_STATE_MAY_INLINE_DATA ext4_block_write_begin ext4_da_write_end ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_write_inline_data_end handle=NULL ext4_journal_stop(handle) ext4_journal_stop ext4_put_nojournal(handle) ref_cnt = (unsigned long)handle BUG_ON(ref_cnt == 0) ---> BUG_ON
The lock held by ext4_convert_inline_data is xattr_sem, but the lock held by generic_perform_write is i_rwsem. Therefore, the two locks can be concurrent.
To solve above issue, we add inode_lock() for ext4_convert_inline_data(). At the same time, move ext4_convert_inline_data() in front of ext4_punch_hole(), remove similar handling from ext4_punch_hole().(CVE-2022-49414)
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected
There is a possibility for mdp5_get_global_state to return -EDEADLK when acquiring the modeset lock, but currently global_state in mdp5_mixer_release doesn't check for if an error is returned.
To avoid a NULL dereference error, let's have mdp5_mixer_release check if an error is returned and propagate that error.
Patchwork: https://patchwork.freedesktop.org/patch/485181/(CVE-2022-49488)
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume
BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3
Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c
Patchwork: https://patchwork.freedesktop.org/patch/483255/ DB: fixed Fixes tag
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: governor: Use kobject release() method to free dbs_data
The struct dbs_data embeds a struct gov_attr_set and the struct gov_attr_set embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreq_dbs_data_release() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe
Call of_node_put(platform_node) to avoid refcount leak in the error path.(CVE-2022-49514)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: avoid null dereference in deinit
If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore.
Avoid this null pointer derefence by skipping the call when necessary.(CVE-2022-49527)
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218(CVE-2022-49532)
In the Linux kernel, the following vulnerability has been resolved:
ipw2x00: Fix potential NULL dereference in libipw_xmit()
crypt and crypt->ops could be null, so we need to checking null before dereference(CVE-2022-49544)
In the Linux kernel, the following vulnerability has been resolved:
be2net: Fix buffer overflow in be_get_module_eeprom
be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case.
Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once.(CVE-2022-49581)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: ralink: Check for null return of devm_kcalloc
Because of the possible failure of the allocation, data->domains might be NULL pointer and will cause the dereference of the NULL pointer later. Therefore, it might be better to check it and directly return -ENOMEM without releasing data manually if fails, because the comment of the devm_kmalloc() says "Memory allocated with this function is automatically freed on driver detach.".(CVE-2022-49608)
In the Linux kernel, the following vulnerability has been resolved:
xtensa: Fix refcount leak bug in time.c
In calibrate_ccount(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.(CVE-2022-49682)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix call trace in setup_tx_descriptors
After PF reset and ethtool -t there was call trace in dmesg sometimes leading to panic. When there was some time, around 5 seconds, between reset and test there were no errors.
Problem was that pf reset calls i40e_vsi_close in prep_for_reset and ethtool -t calls i40e_vsi_close in diag_test. If there was not enough time between those commands the second i40e_vsi_close starts before previous i40e_vsi_close was done which leads to crash.
Add check to diag_test if pf is in reset and don't start offline tests if it is true. Add netif_info("testing failed") into unhappy path of i40e_diag_test()(CVE-2022-49725)
In the Linux kernel, the following vulnerability has been resolved:
nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred
Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well.
Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them.
So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak.
Put those urbs in tx_anchor to avoid the leak, and also fix the error handling.(CVE-2022-49729)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc
A NULL sock pointer is passed into l2cap_sock_alloc() when it is called from l2cap_sock_new_connection_cb() and the error handling paths should also be aware of it.
Seemingly a more elegant solution would be to swap bt_sock_alloc() and l2cap_chan_create() calls since they are not interdependent to that moment but then l2cap_chan_create() adds the soon to be deallocated and still dummy-initialized channel to the global list accessible by many L2CAP paths. The channel would be removed from the list in short period of time but be a bit more straight-forward here and just check for NULL instead of changing the order of function calls.
Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.(CVE-2024-58009)
In the Linux kernel, the following vulnerability has been resolved:
vrf: use RCU protection in l3mdev_l3_out()
l3mdev_l3_out() can be called without RCU being held:
raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out()
Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.(CVE-2025-21791)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2503.4.0.0320.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2503.4.0.0320.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl\n\nHulk Robot reported a KASAN report about use-after-free:\n ==================================================================\n BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160\n Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385\n [...]\n Call Trace:\n klist_dec_and_del+0xa7/0x4a0\n klist_put+0xc7/0x1a0\n device_del+0x4d4/0xed0\n cdev_device_del+0x1a/0x80\n ubi_attach_mtd_dev+0x2951/0x34b0 [ubi]\n ctrl_cdev_ioctl+0x286/0x2f0 [ubi]\n\n Allocated by task 1414:\n device_add+0x60a/0x18b0\n cdev_device_add+0x103/0x170\n ubi_create_volume+0x1118/0x1a10 [ubi]\n ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi]\n\n Freed by task 1385:\n cdev_device_del+0x1a/0x80\n ubi_remove_volume+0x438/0x6c0 [ubi]\n ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi]\n [...]\n ==================================================================\n\nThe lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held\nby ubi_cdev_ioctl is ubi-\u0026gt;device_mutex. Therefore, the two locks can be\nconcurrent.\n\nctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.\nubi_detach is bug-free because it uses reference counting to prevent\nconcurrency. However, uif_init and uif_close in ubi_attach may race with\nubi_cdev_ioctl.\n\nuif_init will race with ubi_cdev_ioctl as in the following stack.\n cpu1 cpu2 cpu3\n_______________________|________________________|______________________\nctrl_cdev_ioctl\n ubi_attach_mtd_dev\n uif_init\n ubi_cdev_ioctl\n ubi_create_volume\n cdev_device_add\n ubi_add_volume\n // sysfs exist\n kill_volumes\n ubi_cdev_ioctl\n ubi_remove_volume\n cdev_device_del\n // first free\n ubi_free_volume\n cdev_del\n // double free\n cdev_device_del\n\nAnd uif_close will race with ubi_cdev_ioctl as in the following stack.\n cpu1 cpu2 cpu3\n_______________________|________________________|______________________\nctrl_cdev_ioctl\n ubi_attach_mtd_dev\n uif_init\n ubi_cdev_ioctl\n ubi_create_volume\n cdev_device_add\n ubi_debugfs_init_dev\n //error goto out_uif;\n uif_close\n kill_volumes\n ubi_cdev_ioctl\n ubi_remove_volume\n cdev_device_del\n // first free\n ubi_free_volume\n // double free\n\nThe cause of this problem is that commit 714fb87e8bc0 make device\n\u0026quot;available\u0026quot; before it becomes accessible via sysfs. Therefore, we\nroll back the modification. We will fix the race condition between\nubi device creation and udev by removing ubi_get_device in\nvol_attribute_show and dev_attribute_show.This avoids accessing\nuninitialized ubi_devices[ubi_num].\n\nubi_get_device is used to prevent devices from being deleted during\nsysfs execution. However, now kernfs ensures that devices will not\nbe deleted before all reference counting are released.\nThe key process is shown in the following stack.\n\ndevice_del\n device_remove_attrs\n device_remove_groups\n sysfs_remove_groups\n sysfs_remove_group\n remove_files\n kernfs_remove_by_name\n kernfs_remove_by_name_ns\n __kernfs_remove\n kernfs_drain(CVE-2021-47634)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix use-after-free in jffs2_clear_xattr_subsystem\n\nWhen we mount a jffs2 image, assume that the first few blocks of\nthe image are normal and contain at least one xattr-related inode,\nbut the next block is abnormal. As a result, an error is returned\nin jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then\ncalled in jffs2_build_filesystem() and then again in\njffs2_do_fill_super().\n\nFinally we can observe the following report:\n ==================================================================\n BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac\n Read of size 8 at addr ffff8881243384e0 by task mount/719\n\n Call Trace:\n dump_stack+0x115/0x16b\n jffs2_clear_xattr_subsystem+0x95/0x6ac\n jffs2_do_fill_super+0x84f/0xc30\n jffs2_fill_super+0x2ea/0x4c0\n mtd_get_sb+0x254/0x400\n mtd_get_sb_by_nr+0x4f/0xd0\n get_tree_mtd+0x498/0x840\n jffs2_get_tree+0x25/0x30\n vfs_get_tree+0x8d/0x2e0\n path_mount+0x50f/0x1e50\n do_mount+0x107/0x130\n __se_sys_mount+0x1c5/0x2f0\n __x64_sys_mount+0xc7/0x160\n do_syscall_64+0x45/0x70\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\n Allocated by task 719:\n kasan_save_stack+0x23/0x60\n __kasan_kmalloc.constprop.0+0x10b/0x120\n kasan_slab_alloc+0x12/0x20\n kmem_cache_alloc+0x1c0/0x870\n jffs2_alloc_xattr_ref+0x2f/0xa0\n jffs2_scan_medium.cold+0x3713/0x4794\n jffs2_do_mount_fs.cold+0xa7/0x2253\n jffs2_do_fill_super+0x383/0xc30\n jffs2_fill_super+0x2ea/0x4c0\n [...]\n\n Freed by task 719:\n kmem_cache_free+0xcc/0x7b0\n jffs2_free_xattr_ref+0x78/0x98\n jffs2_clear_xattr_subsystem+0xa1/0x6ac\n jffs2_do_mount_fs.cold+0x5e6/0x2253\n jffs2_do_fill_super+0x383/0xc30\n jffs2_fill_super+0x2ea/0x4c0\n [...]\n\n The buggy address belongs to the object at ffff8881243384b8\n which belongs to the cache jffs2_xattr_ref of size 48\n The buggy address is located 40 bytes inside of\n 48-byte region [ffff8881243384b8, ffff8881243384e8)\n [...]\n ==================================================================\n\nThe triggering of the BUG is shown in the following stack:\n-----------------------------------------------------------\njffs2_fill_super\n jffs2_do_fill_super\n jffs2_do_mount_fs\n jffs2_build_filesystem\n jffs2_scan_medium\n jffs2_scan_eraseblock \u0026lt;--- ERROR\n jffs2_clear_xattr_subsystem \u0026lt;--- free\n jffs2_clear_xattr_subsystem \u0026lt;--- free again\n-----------------------------------------------------------\n\nAn error is returned in jffs2_do_mount_fs(). If the error is returned\nby jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to\nbe executed. If the error is returned by jffs2_build_filesystem(), the\njffs2_clear_xattr_subsystem() also does not need to be executed again.\nSo move jffs2_clear_xattr_subsystem() from \u0026apos;out_inohash\u0026apos; to \u0026apos;out_root\u0026apos;\nto fix this UAF problem.(CVE-2021-47656)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix unexpected zeroed page mapping with zram swap\n\nTwo processes under CLONE_VM cloning, user process can be corrupted by\nseeing zeroed page unexpectedly.\n\n CPU A CPU B\n\n do_swap_page do_swap_page\n SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path\n swap_readpage valid data\n swap_slot_free_notify\n delete zram entry\n swap_readpage zeroed(invalid) data\n pte_lock\n map the *zero data* to userspace\n pte_unlock\n pte_lock\n if (!pte_same)\n goto out_nomap;\n pte_unlock\n return and next refault will\n read zeroed data\n\nThe swap_slot_free_notify is bogus for CLONE_VM case since it doesn\u0026apos;t\nincrease the refcount of swap slot at copy_mm so it couldn\u0026apos;t catch up\nwhether it\u0026apos;s safe or not to discard data from backing device. In the\ncase, only the lock it could rely on to synchronize swap slot freeing is\npage table lock. Thus, this patch gets rid of the swap_slot_free_notify\nfunction. With this patch, CPU A will see correct data.\n\n CPU A CPU B\n\n do_swap_page do_swap_page\n SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path\n swap_readpage original data\n pte_lock\n map the original data\n swap_free\n swap_range_free\n bd_disk-\u0026gt;fops-\u0026gt;swap_slot_free_notify\n swap_readpage read zeroed data\n pte_unlock\n pte_lock\n if (!pte_same)\n goto out_nomap;\n pte_unlock\n return\n on next refault will see mapped data by CPU B\n\nThe concern of the patch would increase memory consumption since it\ncould keep wasted memory with compressed form in zram as well as\nuncompressed form in address space. However, most of cases of zram uses\nno readahead and do_swap_page is followed by swap_free so it will free\nthe compressed form from in zram quickly.(CVE-2022-49052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: fix a race in rxrpc_exit_net()\n\nCurrent code can lead to the following race:\n\nCPU0 CPU1\n\nrxrpc_exit_net()\n rxrpc_peer_keepalive_worker()\n if (rxnet-\u0026gt;live)\n\n rxnet-\u0026gt;live = false;\n del_timer_sync(\u0026amp;rxnet-\u0026gt;peer_keepalive_timer);\n\n timer_reduce(\u0026amp;rxnet-\u0026gt;peer_keepalive_timer, jiffies + delay);\n\n cancel_work_sync(\u0026amp;rxnet-\u0026gt;peer_keepalive_work);\n\nrxrpc_exit_net() exits while peer_keepalive_timer is still armed,\nleading to use-after-free.\n\nsyzbot report was:\n\nODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0\nWARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505\nModules linked in:\nCPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: netns cleanup_net\nRIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505\nCode: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 \u0026lt;0f\u0026gt; 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3\nRSP: 0018:ffffc9000353fb00 EFLAGS: 00010082\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000\nRDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52\nRBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0\nR13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000\nFS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __debug_check_no_obj_freed lib/debugobjects.c:992 [inline]\n debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023\n kfree+0xd6/0x310 mm/slab.c:3809\n ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176\n ops_free_list net/core/net_namespace.c:174 [inline]\n cleanup_net+0x591/0xb00 net/core/net_namespace.c:598\n process_one_work+0x996/0x1610 kernel/workqueue.c:2289\n worker_thread+0x665/0x1080 kernel/workqueue.c:2436\n kthread+0x2e9/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298\n \u0026lt;/TASK\u0026gt;(CVE-2022-49087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()\n\n[ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020\n[ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]\n[ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1\n[ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018\n[ 12.356356] Call Trace:\n[ 12.358821] dump_stack_lvl+0x34/0x44\n[ 12.362514] check_preemption_disabled+0xd9/0xe0\n[ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]\n[ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx]\n[ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40\n[ 12.384284] local_pci_probe+0x42/0x80\n[ 12.390162] ? pci_match_device+0xd7/0x110\n[ 12.396366] pci_device_probe+0xfd/0x1b0\n[ 12.402372] really_probe+0x1e7/0x3e0\n[ 12.408114] __driver_probe_device+0xfe/0x180\n[ 12.414544] driver_probe_device+0x1e/0x90\n[ 12.420685] __driver_attach+0xc0/0x1c0\n[ 12.426536] ? __device_attach_driver+0xe0/0xe0\n[ 12.433061] ? __device_attach_driver+0xe0/0xe0\n[ 12.439538] bus_for_each_dev+0x78/0xc0\n[ 12.445294] bus_add_driver+0x12b/0x1e0\n[ 12.451021] driver_register+0x8f/0xe0\n[ 12.456631] ? 0xffffffffc07bc000\n[ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx]\n[ 12.468776] do_one_initcall+0x44/0x200\n[ 12.474401] ? load_module+0xad3/0xba0\n[ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410\n[ 12.486268] do_init_module+0x5c/0x280\n[ 12.491730] __do_sys_init_module+0x12e/0x1b0\n[ 12.497785] do_syscall_64+0x3b/0x90\n[ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 12.509764] RIP: 0033:0x7f554f73ab2e(CVE-2022-49155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction\n\nAV/C deferred transaction was supported at a commit 00a7bb81c20f (\u0026quot;ALSA:\nfirewire-lib: Add support for deferred transaction\u0026quot;) while \u0026apos;deferrable\u0026apos;\nflag can be uninitialized for non-control/notify AV/C transactions.\nUBSAN reports it:\n\nkernel: ================================================================================\nkernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9\nkernel: load of value 158 is not a valid value for type \u0026apos;_Bool\u0026apos;\nkernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu\nkernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019\nkernel: Call Trace:\nkernel: \u0026lt;IRQ\u0026gt;\nkernel: show_stack+0x52/0x58\nkernel: dump_stack_lvl+0x4a/0x5f\nkernel: dump_stack+0x10/0x12\nkernel: ubsan_epilogue+0x9/0x45\nkernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49\nkernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib]\nkernel: fcp_response+0x28/0x30 [snd_firewire_lib]\nkernel: fw_core_handle_request+0x230/0x3d0 [firewire_core]\nkernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci]\nkernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci]\nkernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core]\nkernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci]\nkernel: tasklet_action_common.constprop.0+0xea/0xf0\nkernel: tasklet_action+0x22/0x30\nkernel: __do_softirq+0xd9/0x2e3\nkernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0\nkernel: do_softirq+0x75/0xa0\nkernel: \u0026lt;/IRQ\u0026gt;\nkernel: \u0026lt;TASK\u0026gt;\nkernel: __local_bh_enable_ip+0x50/0x60\nkernel: irq_forced_thread_fn+0x7e/0x90\nkernel: irq_thread+0xba/0x190\nkernel: ? irq_thread_fn+0x60/0x60\nkernel: kthread+0x11e/0x140\nkernel: ? irq_thread_check_affinity+0xf0/0xf0\nkernel: ? set_kthread_struct+0x50/0x50\nkernel: ret_from_fork+0x22/0x30\nkernel: \u0026lt;/TASK\u0026gt;\nkernel: ================================================================================\n\nThis commit fixes the bug. The bug has no disadvantage for the non-\ncontrol/notify AV/C transactions since the flag has an effect for AV/C\nresponse with INTERIM (0x0f) status which is not used for the transactions\nin AV/C general specification.(CVE-2022-49248)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix memory leak in jffs2_scan_medium\n\nIf an error is returned in jffs2_scan_eraseblock() and some memory\nhas been added to the jffs2_summary *s, we can observe the following\nkmemleak report:\n\n--------------------------------------------\nunreferenced object 0xffff88812b889c40 (size 64):\n comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838325 (age 34.288s)\n hex dump (first 32 bytes):\n 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P.\n 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................\n backtrace:\n [\u0026lt;ffffffffae93a3a3\u0026gt;] __kmalloc+0x613/0x910\n [\u0026lt;ffffffffaf423b9c\u0026gt;] jffs2_sum_add_dirent_mem+0x5c/0xa0\n [\u0026lt;ffffffffb0f3afa8\u0026gt;] jffs2_scan_medium.cold+0x36e5/0x4794\n [\u0026lt;ffffffffb0f3dbe1\u0026gt;] jffs2_do_mount_fs.cold+0xa7/0x2267\n [\u0026lt;ffffffffaf40acf3\u0026gt;] jffs2_do_fill_super+0x383/0xc30\n [\u0026lt;ffffffffaf40c00a\u0026gt;] jffs2_fill_super+0x2ea/0x4c0\n [\u0026lt;ffffffffb0315d64\u0026gt;] mtd_get_sb+0x254/0x400\n [\u0026lt;ffffffffb0315f5f\u0026gt;] mtd_get_sb_by_nr+0x4f/0xd0\n [\u0026lt;ffffffffb0316478\u0026gt;] get_tree_mtd+0x498/0x840\n [\u0026lt;ffffffffaf40bd15\u0026gt;] jffs2_get_tree+0x25/0x30\n [\u0026lt;ffffffffae9f358d\u0026gt;] vfs_get_tree+0x8d/0x2e0\n [\u0026lt;ffffffffaea7a98f\u0026gt;] path_mount+0x50f/0x1e50\n [\u0026lt;ffffffffaea7c3d7\u0026gt;] do_mount+0x107/0x130\n [\u0026lt;ffffffffaea7c5c5\u0026gt;] __se_sys_mount+0x1c5/0x2f0\n [\u0026lt;ffffffffaea7c917\u0026gt;] __x64_sys_mount+0xc7/0x160\n [\u0026lt;ffffffffb10142f5\u0026gt;] do_syscall_64+0x45/0x70\nunreferenced object 0xffff888114b54840 (size 32):\n comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838325 (age 34.288s)\n hex dump (first 32 bytes):\n c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u..............\n 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk.\n backtrace:\n [\u0026lt;ffffffffae93be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n [\u0026lt;ffffffffaf423b04\u0026gt;] jffs2_sum_add_inode_mem+0x54/0x90\n [\u0026lt;ffffffffb0f3bd44\u0026gt;] jffs2_scan_medium.cold+0x4481/0x4794\n [...]\nunreferenced object 0xffff888114b57280 (size 32):\n comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838393 (age 34.357s)\n hex dump (first 32 bytes):\n 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l.............\n 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk.\n backtrace:\n [\u0026lt;ffffffffae93be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n [\u0026lt;ffffffffaf423c34\u0026gt;] jffs2_sum_add_xattr_mem+0x54/0x90\n [\u0026lt;ffffffffb0f3a24f\u0026gt;] jffs2_scan_medium.cold+0x298c/0x4794\n [...]\nunreferenced object 0xffff8881116cd510 (size 16):\n comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838395 (age 34.355s)\n hex dump (first 16 bytes):\n 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k.\n backtrace:\n [\u0026lt;ffffffffae93be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n [\u0026lt;ffffffffaf423cc4\u0026gt;] jffs2_sum_add_xref_mem+0x54/0x90\n [\u0026lt;ffffffffb0f3b2e3\u0026gt;] jffs2_scan_medium.cold+0x3a20/0x4794\n [...]\n--------------------------------------------\n\nTherefore, we should call jffs2_sum_reset_collected(s) on exit to\nrelease the memory added in s. In addition, a new tag \u0026quot;out_buf\u0026quot; is\nadded to prevent the NULL pointer reference caused by s being NULL.\n(thanks to Zhang Yi for this analysis)(CVE-2022-49276)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix memory leak in jffs2_do_mount_fs\n\nIf jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,\nwe can observe the following kmemleak report:\n\n--------------------------------------------\nunreferenced object 0xffff88811b25a640 (size 64):\n comm \u0026quot;mount\u0026quot;, pid 691, jiffies 4294957728 (age 71.952s)\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 [\u0026lt;ffffffffa493be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n [\u0026lt;ffffffffa5423a06\u0026gt;] jffs2_sum_init+0x86/0x130\n [\u0026lt;ffffffffa5400e58\u0026gt;] jffs2_do_mount_fs+0x798/0xac0\n [\u0026lt;ffffffffa540acf3\u0026gt;] jffs2_do_fill_super+0x383/0xc30\n [\u0026lt;ffffffffa540c00a\u0026gt;] jffs2_fill_super+0x2ea/0x4c0\n [...]\nunreferenced object 0xffff88812c760000 (size 65536):\n comm \u0026quot;mount\u0026quot;, pid 691, jiffies 4294957728 (age 71.952s)\n hex dump (first 32 bytes):\n bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................\n bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................\n backtrace:\n [\u0026lt;ffffffffa493a449\u0026gt;] __kmalloc+0x6b9/0x910\n [\u0026lt;ffffffffa5423a57\u0026gt;] jffs2_sum_init+0xd7/0x130\n [\u0026lt;ffffffffa5400e58\u0026gt;] jffs2_do_mount_fs+0x798/0xac0\n [\u0026lt;ffffffffa540acf3\u0026gt;] jffs2_do_fill_super+0x383/0xc30\n [\u0026lt;ffffffffa540c00a\u0026gt;] jffs2_fill_super+0x2ea/0x4c0\n [...]\n--------------------------------------------\n\nThis is because the resources allocated in jffs2_sum_init() are not\nreleased. Call jffs2_sum_exit() to release these resources to solve\nthe problem.(CVE-2022-49277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()\n\nThere is a deadlock in rtllib_beacons_stop(), which is shown\nbelow:\n\n (Thread 1) | (Thread 2)\n | rtllib_send_beacon()\nrtllib_beacons_stop() | mod_timer()\n spin_lock_irqsave() //(1) | (wait a time)\n ... | rtllib_send_beacon_cb()\n del_timer_sync() | spin_lock_irqsave() //(2)\n (wait timer to stop) | ...\n\nWe hold ieee-\u0026gt;beacon_lock in position (1) of thread 1 and\nuse del_timer_sync() to wait timer to stop, but timer handler\nalso need ieee-\u0026gt;beacon_lock in position (2) of thread 2.\nAs a result, rtllib_beacons_stop() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_irqsave(), which could let timer handler to obtain\nthe needed lock.(CVE-2022-49315)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmips: cpc: Fix refcount leak in mips_cpc_default_phys_base\n\nAdd the missing of_node_put() to release the refcount incremented\nby of_find_compatible_node().(CVE-2022-49324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling\n\nError paths do not free previously allocated memory. Add devm_kfree() to\nthose failure paths.(CVE-2022-49331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: mt6397: 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.(CVE-2022-49375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix race condition between ext4_write and ext4_convert_inline_data\n\nHulk Robot reported a BUG_ON:\n ==================================================================\n EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0,\n block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters\n kernel BUG at fs/ext4/ext4_jbd2.c:53!\n invalid opcode: 0000 [#1] SMP KASAN PTI\n CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1\n RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline]\n RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116\n [...]\n Call Trace:\n ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795\n generic_perform_write+0x279/0x3c0 mm/filemap.c:3344\n ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270\n ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520\n do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732\n do_iter_write+0x107/0x430 fs/read_write.c:861\n vfs_writev fs/read_write.c:934 [inline]\n do_pwritev+0x1e5/0x380 fs/read_write.c:1031\n [...]\n ==================================================================\n\nAbove issue may happen as follows:\n cpu1 cpu2\n__________________________|__________________________\ndo_pwritev\n vfs_writev\n do_iter_write\n ext4_file_write_iter\n ext4_buffered_write_iter\n generic_perform_write\n ext4_da_write_begin\n vfs_fallocate\n ext4_fallocate\n ext4_convert_inline_data\n ext4_convert_inline_data_nolock\n ext4_destroy_inline_data_nolock\n clear EXT4_STATE_MAY_INLINE_DATA\n ext4_map_blocks\n ext4_ext_map_blocks\n ext4_mb_new_blocks\n ext4_mb_regular_allocator\n ext4_mb_good_group_nolock\n ext4_mb_init_group\n ext4_mb_init_cache\n ext4_mb_generate_buddy --\u0026gt; error\n ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)\n ext4_restore_inline_data\n set EXT4_STATE_MAY_INLINE_DATA\n ext4_block_write_begin\n ext4_da_write_end\n ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)\n ext4_write_inline_data_end\n handle=NULL\n ext4_journal_stop(handle)\n __ext4_journal_stop\n ext4_put_nojournal(handle)\n ref_cnt = (unsigned long)handle\n BUG_ON(ref_cnt == 0) ---\u0026gt; BUG_ON\n\nThe lock held by ext4_convert_inline_data is xattr_sem, but the lock\nheld by generic_perform_write is i_rwsem. Therefore, the two locks can\nbe concurrent.\n\nTo solve above issue, we add inode_lock() for ext4_convert_inline_data().\nAt the same time, move ext4_convert_inline_data() in front of\next4_punch_hole(), remove similar handling from ext4_punch_hole().(CVE-2022-49414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected\n\nThere is a possibility for mdp5_get_global_state to return\n-EDEADLK when acquiring the modeset lock, but currently global_state in\nmdp5_mixer_release doesn\u0026apos;t check for if an error is returned.\n\nTo avoid a NULL dereference error, let\u0026apos;s have mdp5_mixer_release\ncheck if an error is returned and propagate that error.\n\nPatchwork: https://patchwork.freedesktop.org/patch/485181/(CVE-2022-49488)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume\n\nBUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3\n\nCall trace:\n dpu_vbif_init_memtypes+0x40/0xb8\n dpu_runtime_resume+0xcc/0x1c0\n pm_generic_runtime_resume+0x30/0x44\n __genpd_runtime_resume+0x68/0x7c\n genpd_runtime_resume+0x134/0x258\n __rpm_callback+0x98/0x138\n rpm_callback+0x30/0x88\n rpm_resume+0x36c/0x49c\n __pm_runtime_resume+0x80/0xb0\n dpu_core_irq_uninstall+0x30/0xb0\n dpu_irq_uninstall+0x18/0x24\n msm_drm_uninit+0xd8/0x16c\n\nPatchwork: https://patchwork.freedesktop.org/patch/483255/\n[DB: fixed Fixes tag](CVE-2022-49489)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: governor: Use kobject release() method to free dbs_data\n\nThe struct dbs_data embeds a struct gov_attr_set and\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\na release() method and we can\u0026apos;t use kfree() to free it directly,\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\nthe kobject::release() method. This fixes the calltrace like below:\n\n ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\n WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n Modules linked in:\n CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\n Hardware name: Marvell OcteonTX CN96XX board (DT)\n pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : debug_print_object+0xb8/0x100\n lr : debug_print_object+0xb8/0x100\n sp : ffff80001dfcf9a0\n x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\n x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\n x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\n x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\n x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\n x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\n x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\n x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\n x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\n Call trace:\n debug_print_object+0xb8/0x100\n __debug_check_no_obj_freed+0x1d0/0x25c\n debug_check_no_obj_freed+0x24/0xa0\n kfree+0x11c/0x440\n cpufreq_dbs_governor_exit+0xa8/0xac\n cpufreq_exit_governor+0x44/0x90\n cpufreq_set_policy+0x29c/0x570\n store_scaling_governor+0x110/0x154\n store+0xb0/0xe0\n sysfs_kf_write+0x58/0x84\n kernfs_fop_write_iter+0x12c/0x1c0\n new_sync_write+0xf0/0x18c\n vfs_write+0x1cc/0x220\n ksys_write+0x74/0x100\n __arm64_sys_write+0x28/0x3c\n invoke_syscall.constprop.0+0x58/0xf0\n do_el0_svc+0x70/0x170\n el0_svc+0x54/0x190\n el0t_64_sync_handler+0xa4/0x130\n el0t_64_sync+0x1a0/0x1a4\n irq event stamp: 189006\n hardirqs last enabled at (189005): [\u0026lt;ffff8000080849d0\u0026gt;] finish_task_switch.isra.0+0xe0/0x2c0\n hardirqs last disabled at (189006): [\u0026lt;ffff8000090667a4\u0026gt;] el1_dbg+0x24/0xa0\n softirqs last enabled at (188966): [\u0026lt;ffff8000080106d0\u0026gt;] __do_softirq+0x4b0/0x6a0\n softirqs last disabled at (188957): [\u0026lt;ffff80000804a618\u0026gt;] __irq_exit_rcu+0x108/0x1a4\n\n[ rjw: Because can be freed by the gov_attr_set_put() in\n cpufreq_dbs_governor_exit() now, it is also necessary to put the\n invocation of the governor -\u0026gt;exit() callback into the new\n cpufreq_dbs_data_release() function. ](CVE-2022-49513)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe\n\nCall of_node_put(platform_node) to avoid refcount leak in\nthe error path.(CVE-2022-49514)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: avoid null dereference in deinit\n\nIf venus_probe fails at pm_runtime_put_sync the error handling first\ncalls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets\ncore-\u0026gt;ops to NULL, hfi_core_deinit cannot call the core_deinit function\nanymore.\n\nAvoid this null pointer derefence by skipping the call when necessary.(CVE-2022-49527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes\n\ndrm_cvt_mode may return NULL and we should check it.\n\nThis bug is found by syzkaller:\n\nFAULT_INJECTION stacktrace:\n[ 168.567394] FAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 1\n[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1\n[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n[ 168.567408] Call trace:\n[ 168.567414] dump_backtrace+0x0/0x310\n[ 168.567418] show_stack+0x28/0x38\n[ 168.567423] dump_stack+0xec/0x15c\n[ 168.567427] should_fail+0x3ac/0x3d0\n[ 168.567437] __should_failslab+0xb8/0x120\n[ 168.567441] should_failslab+0x28/0xc0\n[ 168.567445] kmem_cache_alloc_trace+0x50/0x640\n[ 168.567454] drm_mode_create+0x40/0x90\n[ 168.567458] drm_cvt_mode+0x48/0xc78\n[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]\n[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80\n[ 168.567492] drm_mode_getconnector+0x2e0/0xa70\n[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8\n[ 168.567514] drm_ioctl+0x558/0x6d0\n[ 168.567522] do_vfs_ioctl+0x160/0xf30\n[ 168.567525] ksys_ioctl+0x98/0xd8\n[ 168.567530] __arm64_sys_ioctl+0x50/0xc8\n[ 168.567536] el0_svc_common+0xc8/0x320\n[ 168.567540] el0_svc_handler+0xf8/0x160\n[ 168.567544] el0_svc+0x10/0x218\n\nKASAN stacktrace:\n[ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]\n[ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425\n[ 168.567566]\n[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1\n[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n[ 168.567575] Call trace:\n[ 168.567578] dump_backtrace+0x0/0x310\n[ 168.567582] show_stack+0x28/0x38\n[ 168.567586] dump_stack+0xec/0x15c\n[ 168.567591] kasan_report+0x244/0x2f0\n[ 168.567594] __asan_load4+0x58/0xb0\n[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]\n[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80\n[ 168.567617] drm_mode_getconnector+0x2e0/0xa70\n[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8\n[ 168.567624] drm_ioctl+0x558/0x6d0\n[ 168.567628] do_vfs_ioctl+0x160/0xf30\n[ 168.567632] ksys_ioctl+0x98/0xd8\n[ 168.567636] __arm64_sys_ioctl+0x50/0xc8\n[ 168.567641] el0_svc_common+0xc8/0x320\n[ 168.567645] el0_svc_handler+0xf8/0x160\n[ 168.567649] el0_svc+0x10/0x218(CVE-2022-49532)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipw2x00: Fix potential NULL dereference in libipw_xmit()\n\ncrypt and crypt-\u0026gt;ops could be null, so we need to checking null\nbefore dereference(CVE-2022-49544)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbe2net: Fix buffer overflow in be_get_module_eeprom\n\nbe_cmd_read_port_transceiver_data assumes that it is given a buffer that\nis at least PAGE_DATA_LEN long, or twice that if the module supports SFF\n8472. However, this is not always the case.\n\nFix this by passing the desired offset and length to\nbe_cmd_read_port_transceiver_data so that we only copy the bytes once.(CVE-2022-49581)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: ralink: Check for null return of devm_kcalloc\n\nBecause of the possible failure of the allocation, data-\u0026gt;domains might\nbe NULL pointer and will cause the dereference of the NULL pointer\nlater.\nTherefore, it might be better to check it and directly return -ENOMEM\nwithout releasing data manually if fails, because the comment of the\ndevm_kmalloc() says \u0026quot;Memory allocated with this function is\nautomatically freed on driver detach.\u0026quot;.(CVE-2022-49608)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxtensa: Fix refcount leak bug in time.c\n\nIn calibrate_ccount(), of_find_compatible_node() will return a node\npointer with refcount incremented. We should use of_node_put() when\nit is not used anymore.(CVE-2022-49682)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix call trace in setup_tx_descriptors\n\nAfter PF reset and ethtool -t there was call trace in dmesg\nsometimes leading to panic. When there was some time, around 5\nseconds, between reset and test there were no errors.\n\nProblem was that pf reset calls i40e_vsi_close in prep_for_reset\nand ethtool -t calls i40e_vsi_close in diag_test. If there was not\nenough time between those commands the second i40e_vsi_close starts\nbefore previous i40e_vsi_close was done which leads to crash.\n\nAdd check to diag_test if pf is in reset and don\u0026apos;t start offline\ntests if it is true.\nAdd netif_info(\u0026quot;testing failed\u0026quot;) into unhappy path of i40e_diag_test()(CVE-2022-49725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred\n\nSimilar to the handling of play_deferred in commit 19cfe912c37b\n(\u0026quot;Bluetooth: btusb: Fix memory leak in play_deferred\u0026quot;), we thought\na patch might be needed here as well.\n\nCurrently usb_submit_urb is called directly to submit deferred tx\nurbs after unanchor them.\n\nSo the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb\nand cause memory leak.\n\nPut those urbs in tx_anchor to avoid the leak, and also fix the error\nhandling.(CVE-2022-49729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc\n\nA NULL sock pointer is passed into l2cap_sock_alloc() when it is called\nfrom l2cap_sock_new_connection_cb() and the error handling paths should\nalso be aware of it.\n\nSeemingly a more elegant solution would be to swap bt_sock_alloc() and\nl2cap_chan_create() calls since they are not interdependent to that moment\nbut then l2cap_chan_create() adds the soon to be deallocated and still\ndummy-initialized channel to the global list accessible by many L2CAP\npaths. The channel would be removed from the list in short period of time\nbut be a bit more straight-forward here and just check for NULL instead of\nchanging the order of function calls.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE static\nanalysis tool.(CVE-2024-58009)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvrf: use RCU protection in l3mdev_l3_out()\n\nl3mdev_l3_out() can be called without RCU being held:\n\nraw_sendmsg()\n ip_push_pending_frames()\n ip_send_skb()\n ip_local_out()\n __ip_local_out()\n l3mdev_ip_out()\n\nAdd rcu_read_lock() / rcu_read_unlock() pair to avoid\na potential UAF.(CVE-2025-21791)",
"id": "OESA-2025-1317",
"modified": "2026-08-06T11:08:25Z",
"published": "2025-03-21T11:08:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1317"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47634"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47656"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49155"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49248"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49277"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49315"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49331"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49375"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49414"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49488"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49489"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49513"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49514"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49532"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49581"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49608"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49682"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58009"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21791"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47634",
"CVE-2021-47656",
"CVE-2022-49052",
"CVE-2022-49087",
"CVE-2022-49155",
"CVE-2022-49248",
"CVE-2022-49276",
"CVE-2022-49277",
"CVE-2022-49315",
"CVE-2022-49324",
"CVE-2022-49331",
"CVE-2022-49375",
"CVE-2022-49414",
"CVE-2022-49488",
"CVE-2022-49489",
"CVE-2022-49513",
"CVE-2022-49514",
"CVE-2022-49527",
"CVE-2022-49532",
"CVE-2022-49544",
"CVE-2022-49581",
"CVE-2022-49608",
"CVE-2022-49682",
"CVE-2022-49725",
"CVE-2022-49729",
"CVE-2024-58009",
"CVE-2025-21791"
]
}
oesa-2025-1409
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix some memory leaks in an error handling path of 'log_replay()'
All error handling paths lead to 'out' where many resources are freed.
Do it as well here instead of a direct return, otherwise 'log', 'ra' and 'log->one_page_buf' (at least) will leak.(CVE-2021-47660)
In the Linux kernel, the following vulnerability has been resolved:
list: fix a data-race around ep->rdllist
ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing.
Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless ep_events_available(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last ep_events_available() lockless.
BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait
write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0xffff88810480c7d0 -> 0xffff888103c15098
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: governor: Use kobject release() method to free dbs_data
The struct dbs_data embeds a struct gov_attr_set and the struct gov_attr_set embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreq_dbs_data_release() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate BOOT sectors_per_clusters
When the NTFS BOOT sectors_per_clusters field is > 0x80, it represents a shift value. Make sure that the shift value is not too large before using it (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.
This prevents negative shift values and shift values that are larger than the field size.
Prevents this UBSAN error:
UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16 shift exponent -192 is negative(CVE-2022-49553)
In the Linux kernel, the following vulnerability has been resolved:
drm/drm_vma_manager: Add drm_vma_node_allow_once()
Currently there is no easy way for a drm driver to safely check and allow drm_vma_offset_node for a drm file just once. Allow drm drivers to call non-refcounted version of drm_vma_node_allow() so that a driver doesn't need to keep track of each drm_vma_node_allow() to call subsequent drm_vma_node_revoke() to prevent memory leak.(CVE-2023-53001)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free of kernel socket in cleanup_bearer().
syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1]
When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer().
tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free.
Let's move the decrement after releasing the socket in cleanup_bearer().
[0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830
[1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer(CVE-2024-56642)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix race between element replace and close()
Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element:
// set map[0] = s0 map_update_elem(map, 0, s0)
// drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk)
Then close(map) enqueues bpf_map_free_deferred, which finally calls sock_map_free(). This results in some refcount_t warnings along with a KASAN splat [1].
Fix __sock_map_delete(), do not allow sock_map_unref() on elements that may have been replaced.
[1]: BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330 Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063
CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred Call Trace: <TASK> dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30
The bu ---truncated---(CVE-2024-56664)
In the Linux kernel, the following vulnerability has been resolved:
hrtimers: Handle CPU state correctly on hotplug
Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to CPUHP_ONLINE:
Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set to 1 throughout. However, during a CPU unplug operation, the tick and the clockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online state, for instance CFS incorrectly assumes that the hrtick is already active, and the chance of the clockevent device to transition to oneshot mode is also lost forever for the CPU, unless it goes back to a lower state than CPUHP_HRTIMERS_PREPARE once.
This round-trip reveals another issue; cpu_base.online is not set to 1 after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().
Aside of that, the bulk of the per CPU state is not reset either, which means there are dangling pointers in the worst case.
Address this by adding a corresponding startup() callback, which resets the stale per CPU state and sets the online flag.
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_tcm: Don't free command immediately
Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.(CVE-2024-58055)
In the Linux kernel, the following vulnerability has been resolved:
net: davicom: fix UAF in dm9000_drv_remove
dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.
This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").
This bug is detected by our static analysis tool.(CVE-2025-21715)
In the Linux kernel, the following vulnerability has been resolved:
net: rose: fix timer races against user threads
Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread.
Add a check and rearm the timers if needed.
BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ>(CVE-2025-21718)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: do not force clear folio if buffer is referenced
Patch series "nilfs2: protect busy buffer heads from being force-cleared".
This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue.
This patch (of 2):
Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur.
One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state:
WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be:
WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>
Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback.
Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.(CVE-2025-21722)
In the Linux kernel, the following vulnerability has been resolved:
padata: avoid UAF for reorder_work
Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below:
crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }
padata_do_serial
// new request added
list_add
// sees the new request
queue_work(reorder_work)
padata_reorder
queue_work_on(squeue->work)
...
<kworker context>
padata_serial_worker
// completes new request,
// no more outstanding
// requests
crypto_del_alg
// free pd
<kworker context> invoke_padata_reorder // UAF of pd
To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.(CVE-2025-21726)
In the Linux kernel, the following vulnerability has been resolved:
padata: fix UAF in padata_reorder
A bug was found when run ltp test:
BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206
CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0
If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01).
This can be explained as bellow:
pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF }
In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF.
As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish.
[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)
In the Linux kernel, the following vulnerability has been resolved:
arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array
The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).(CVE-2025-21785)
In the Linux kernel, the following vulnerability has been resolved:
vrf: use RCU protection in l3mdev_l3_out()
l3mdev_l3_out() can be called without RCU being held:
raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out()
Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.(CVE-2025-21791)
In the Linux kernel, the following vulnerability has been resolved:
PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()
The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior.
Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows:
$ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :
Sometimes, garbage may appear after the colon.
In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack.
Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows:
$ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3
In the Linux kernel, the following vulnerability has been resolved:
hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING
hrtimers are migrated away from the dying CPU to any online target at the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers handling tasks involved in the CPU hotplug forward progress.
However wakeups can still be performed by the outgoing CPU after CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being armed. Depending on several considerations (crystal ball power management based election, earliest timer already enqueued, timer migration enabled or not), the target may eventually be the current CPU even if offline. If that happens, the timer is eventually ignored.
The most notable example is RCU which had to deal with each and every of those wake-ups by deferring them to an online CPU, along with related workarounds:
_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying) _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU) _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)
The problem isn't confined to RCU though as the stop machine kthread (which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end of its work through cpu_stop_signal_done() and performs a wake up that eventually arms the deadline server timer:
WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace: <TASK> start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_thread
Instead of providing yet another bandaid to work around the situation, fix it in the hrtimers infrastructure instead: always migrate away a timer to an online target whenever it is enqueued from an offline CPU.
This will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Drop unmanaged ELP metric worker
The ELP worker needs to calculate new metric values for all neighbors "reachable" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context.
Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses.
Directly canceling the metric worker also has various problems:
- cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish.
- iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)
The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by:
- creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context
- only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)(CVE-2025-21823)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: prevent opcode speculation
sqe->opcode is used for different tables, make sure we santitise it against speculations.(CVE-2025-21863)
In the Linux kernel, the following vulnerability has been resolved:
uprobes: Reject the shared zeropage in uprobe_write_opcode()
We triggered the following crash in syzkaller tests:
BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint.part.0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0 __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280 __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2
BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1
The following syzkaller test case can be used to reproduce:
r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)
The cause is that zero pfn is set to the PTE without increasing the RSS count in mfill_atomic_pte_zeropage() and the refcount of zero folio does not increase accordingly. Then, the operation on the same pfn is performed in uprobe_write_opcode()->__replace_page() to unconditional decrease the RSS count and old_folio's refcount.
Therefore, two bugs are introduced:
-
The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count".
-
The reserved folio (zero folio) is freed when folio->refcount is zero, then free_pages_prepare->free_page_is_bad() report error "Bad page state".
There is more, the following warning could also theoretically be triggered:
__replace_page() -> ... -> folio_remove_rmap_pte() -> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)
Considering that uprobe hit on the zero folio is a very rare case, just reject zero old folio immediately after get_user_page_vma_remote().
mingo: Cleaned up the changelog
In the Linux kernel, the following vulnerability has been resolved:
ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up
The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote().
Move dput(upper) after its last use to prevent use-after-free.
BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167
Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... </TASK>(CVE-2025-21887)
In the Linux kernel, the following vulnerability has been resolved:
gpio: aggregator: protect driver attr handlers against module unload
Both new_device_store and delete_device_store touch module global resources (e.g. gpio_aggregator_lock). To prevent race conditions with module unload, a reference needs to be held.
Add try_module_get() in these handlers.
For new_device_store, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems:
#!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait
Starting with the following warning, several kinds of warnings will appear and the system may become unstable:
------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: <TASK> ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]---(CVE-2025-21943)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"perf-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-259.0.0.161.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"perf-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-259.0.0.161.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix some memory leaks in an error handling path of \u0026apos;log_replay()\u0026apos;\n\nAll error handling paths lead to \u0026apos;out\u0026apos; where many resources are freed.\n\nDo it as well here instead of a direct return, otherwise \u0026apos;log\u0026apos;, \u0026apos;ra\u0026apos; and\n\u0026apos;log-\u0026gt;one_page_buf\u0026apos; (at least) will leak.(CVE-2021-47660)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlist: fix a data-race around ep-\u0026gt;rdllist\n\nep_poll() first calls ep_events_available() with no lock held and checks\nif ep-\u0026gt;rdllist is empty by list_empty_careful(), which reads\nrdllist-\u0026gt;prev. Thus all accesses to it need some protection to avoid\nstore/load-tearing.\n\nNote INIT_LIST_HEAD_RCU() already has the annotation for both prev\nand next.\n\nCommit bf3b9f6372c4 (\u0026quot;epoll: Add busy poll support to epoll with socket\nfds.\u0026quot;) added the first lockless ep_events_available(), and commit\nc5a282e9635e (\u0026quot;fs/epoll: reduce the scope of wq lock in epoll_wait()\u0026quot;)\nmade some ep_events_available() calls lockless and added single call under\na lock, finally commit e59d3c64cba6 (\u0026quot;epoll: eliminate unnecessary lock\nfor zero timeout\u0026quot;) made the last ep_events_available() lockless.\n\nBUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait\n\nwrite to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:\n INIT_LIST_HEAD include/linux/list.h:38 [inline]\n list_splice_init include/linux/list.h:492 [inline]\n ep_start_scan fs/eventpoll.c:622 [inline]\n ep_send_events fs/eventpoll.c:1656 [inline]\n ep_poll fs/eventpoll.c:1806 [inline]\n do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nread to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:\n list_empty_careful include/linux/list.h:329 [inline]\n ep_events_available fs/eventpoll.c:381 [inline]\n ep_poll fs/eventpoll.c:1797 [inline]\n do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nvalue changed: 0xffff88810480c7d0 -\u0026gt; 0xffff888103c15098\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: governor: Use kobject release() method to free dbs_data\n\nThe struct dbs_data embeds a struct gov_attr_set and\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\na release() method and we can\u0026apos;t use kfree() to free it directly,\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\nthe kobject::release() method. This fixes the calltrace like below:\n\n ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\n WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n Modules linked in:\n CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\n Hardware name: Marvell OcteonTX CN96XX board (DT)\n pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : debug_print_object+0xb8/0x100\n lr : debug_print_object+0xb8/0x100\n sp : ffff80001dfcf9a0\n x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\n x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\n x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\n x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\n x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\n x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\n x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\n x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\n x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\n Call trace:\n debug_print_object+0xb8/0x100\n __debug_check_no_obj_freed+0x1d0/0x25c\n debug_check_no_obj_freed+0x24/0xa0\n kfree+0x11c/0x440\n cpufreq_dbs_governor_exit+0xa8/0xac\n cpufreq_exit_governor+0x44/0x90\n cpufreq_set_policy+0x29c/0x570\n store_scaling_governor+0x110/0x154\n store+0xb0/0xe0\n sysfs_kf_write+0x58/0x84\n kernfs_fop_write_iter+0x12c/0x1c0\n new_sync_write+0xf0/0x18c\n vfs_write+0x1cc/0x220\n ksys_write+0x74/0x100\n __arm64_sys_write+0x28/0x3c\n invoke_syscall.constprop.0+0x58/0xf0\n do_el0_svc+0x70/0x170\n el0_svc+0x54/0x190\n el0t_64_sync_handler+0xa4/0x130\n el0t_64_sync+0x1a0/0x1a4\n irq event stamp: 189006\n hardirqs last enabled at (189005): [\u0026lt;ffff8000080849d0\u0026gt;] finish_task_switch.isra.0+0xe0/0x2c0\n hardirqs last disabled at (189006): [\u0026lt;ffff8000090667a4\u0026gt;] el1_dbg+0x24/0xa0\n softirqs last enabled at (188966): [\u0026lt;ffff8000080106d0\u0026gt;] __do_softirq+0x4b0/0x6a0\n softirqs last disabled at (188957): [\u0026lt;ffff80000804a618\u0026gt;] __irq_exit_rcu+0x108/0x1a4\n\n[ rjw: Because can be freed by the gov_attr_set_put() in\n cpufreq_dbs_governor_exit() now, it is also necessary to put the\n invocation of the governor -\u0026gt;exit() callback into the new\n cpufreq_dbs_data_release() function. ](CVE-2022-49513)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: validate BOOT sectors_per_clusters\n\nWhen the NTFS BOOT sectors_per_clusters field is \u0026gt; 0x80, it represents a\nshift value. Make sure that the shift value is not too large before using\nit (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.\n\nThis prevents negative shift values and shift values that are larger than\nthe field size.\n\nPrevents this UBSAN error:\n\n UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16\n shift exponent -192 is negative(CVE-2022-49553)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_vma_manager: Add drm_vma_node_allow_once()\n\nCurrently there is no easy way for a drm driver to safely check and allow\ndrm_vma_offset_node for a drm file just once. Allow drm drivers to call\nnon-refcounted version of drm_vma_node_allow() so that a driver doesn\u0026apos;t\nneed to keep track of each drm_vma_node_allow() to call subsequent\ndrm_vma_node_revoke() to prevent memory leak.(CVE-2023-53001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free of kernel socket in cleanup_bearer().\n\nsyzkaller reported a use-after-free of UDP kernel socket\nin cleanup_bearer() without repro. [0][1]\n\nWhen bearer_disable() calls tipc_udp_disable(), cleanup\nof the UDP kernel socket is deferred by work calling\ncleanup_bearer().\n\ntipc_exit_net() waits for such works to finish by checking\ntipc_net(net)-\u0026gt;wq_count. However, the work decrements the\ncount too early before releasing the kernel socket,\nunblocking cleanup_net() and resulting in use-after-free.\n\nLet\u0026apos;s move the decrement after releasing the socket in\ncleanup_bearer().\n\n[0]:\nref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at\n sk_alloc+0x438/0x608\n inet_create+0x4c8/0xcb0\n __sock_create+0x350/0x6b8\n sock_create_kern+0x58/0x78\n udp_sock_create4+0x68/0x398\n udp_sock_create+0x88/0xc8\n tipc_udp_enable+0x5e8/0x848\n __tipc_nl_bearer_enable+0x84c/0xed8\n tipc_nl_bearer_enable+0x38/0x60\n genl_family_rcv_msg_doit+0x170/0x248\n genl_rcv_msg+0x400/0x5b0\n netlink_rcv_skb+0x1dc/0x398\n genl_rcv+0x44/0x68\n netlink_unicast+0x678/0x8b0\n netlink_sendmsg+0x5e4/0x898\n ____sys_sendmsg+0x500/0x830\n\n[1]:\nBUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]\nBUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n udp_hashslot include/net/udp.h:85 [inline]\n udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n sk_common_release+0xaf/0x3f0 net/core/sock.c:3820\n inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437\n inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489\n __sock_release net/socket.c:658 [inline]\n sock_release+0xa0/0x210 net/socket.c:686\n cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nUninit was created at:\n slab_free_hook mm/slub.c:2269 [inline]\n slab_free mm/slub.c:4580 [inline]\n kmem_cache_free+0x207/0xc40 mm/slub.c:4682\n net_free net/core/net_namespace.c:454 [inline]\n cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nCPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: events cleanup_bearer(CVE-2024-56642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix race between element replace and close()\n\nElement replace (with a socket different from the one stored) may race\nwith socket\u0026apos;s close() link popping \u0026amp; unlinking. __sock_map_delete()\nunconditionally unrefs the (wrong) element:\n\n// set map[0] = s0\nmap_update_elem(map, 0, s0)\n\n// drop fd of s0\nclose(s0)\n sock_map_close()\n lock_sock(sk) (s0!)\n sock_map_remove_links(sk)\n link = sk_psock_link_pop()\n sock_map_unlink(sk, link)\n sock_map_delete_from_link\n // replace map[0] with s1\n map_update_elem(map, 0, s1)\n sock_map_update_elem\n (s1!) lock_sock(sk)\n sock_map_update_common\n psock = sk_psock(sk)\n spin_lock(\u0026amp;stab-\u0026gt;lock)\n osk = stab-\u0026gt;sks[idx]\n sock_map_add_link(..., \u0026amp;stab-\u0026gt;sks[idx])\n sock_map_unref(osk, \u0026amp;stab-\u0026gt;sks[idx])\n psock = sk_psock(osk)\n sk_psock_put(sk, psock)\n if (refcount_dec_and_test(\u0026amp;psock))\n sk_psock_drop(sk, psock)\n spin_unlock(\u0026amp;stab-\u0026gt;lock)\n unlock_sock(sk)\n __sock_map_delete\n spin_lock(\u0026amp;stab-\u0026gt;lock)\n sk = *psk // s1 replaced s0; sk == s1\n if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch\n sk = xchg(psk, NULL)\n if (sk)\n sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle\n psock = sk_psock(sk)\n sk_psock_put(sk, psock)\n if (refcount_dec_and_test())\n sk_psock_drop(sk, psock)\n spin_unlock(\u0026amp;stab-\u0026gt;lock)\n release_sock(sk)\n\nThen close(map) enqueues bpf_map_free_deferred, which finally calls\nsock_map_free(). This results in some refcount_t warnings along with\na KASAN splat [1].\n\nFix __sock_map_delete(), do not allow sock_map_unref() on elements that\nmay have been replaced.\n\n[1]:\nBUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330\nWrite of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063\n\nCPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\nWorkqueue: events_unbound bpf_map_free_deferred\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x68/0x90\n print_report+0x174/0x4f6\n kasan_report+0xb9/0x190\n kasan_check_range+0x10f/0x1e0\n sock_map_free+0x10e/0x330\n bpf_map_free_deferred+0x173/0x320\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 1202:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n __kasan_slab_alloc+0x85/0x90\n kmem_cache_alloc_noprof+0x131/0x450\n sk_prot_alloc+0x5b/0x220\n sk_alloc+0x2c/0x870\n unix_create1+0x88/0x8a0\n unix_create+0xc5/0x180\n __sock_create+0x241/0x650\n __sys_socketpair+0x1ce/0x420\n __x64_sys_socketpair+0x92/0x100\n do_syscall_64+0x93/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 46:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x37/0x60\n __kasan_slab_free+0x4b/0x70\n kmem_cache_free+0x1a1/0x590\n __sk_destruct+0x388/0x5a0\n sk_psock_destroy+0x73e/0xa50\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n\nThe bu\n---truncated---(CVE-2024-56664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Handle CPU state correctly on hotplug\n\nConsider a scenario where a CPU transitions from CPUHP_ONLINE to halfway\nthrough a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to\nCPUHP_ONLINE:\n\nSince hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set\nto 1 throughout. However, during a CPU unplug operation, the tick and the\nclockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online\nstate, for instance CFS incorrectly assumes that the hrtick is already\nactive, and the chance of the clockevent device to transition to oneshot\nmode is also lost forever for the CPU, unless it goes back to a lower state\nthan CPUHP_HRTIMERS_PREPARE once.\n\nThis round-trip reveals another issue; cpu_base.online is not set to 1\nafter the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().\n\nAside of that, the bulk of the per CPU state is not reset either, which\nmeans there are dangling pointers in the worst case.\n\nAddress this by adding a corresponding startup() callback, which resets the\nstale per CPU state and sets the online flag.\n\n[ tglx: Make the new callback unconditionally available, remove the online\n \tmodification in the prepare() callback and clear the remaining\n \tstate in the starting callback instead of the prepare callback ](CVE-2024-57951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_tcm: Don\u0026apos;t free command immediately\n\nDon\u0026apos;t prematurely free the command. Wait for the status completion of\nthe sense status. It can be freed then. Otherwise we will double-free\nthe command.(CVE-2024-58055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: davicom: fix UAF in dm9000_drv_remove\n\ndm is netdev private data and it cannot be\nused after free_netdev() call. Using dm after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.\n\nThis is similar to the issue fixed in commit\nad297cd2db89 (\u0026quot;net: qcom/emac: fix UAF in emac_remove\u0026quot;).\n\nThis bug is detected by our static analysis tool.(CVE-2025-21715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: rose: fix timer races against user threads\n\nRose timers only acquire the socket spinlock, without\nchecking if the socket is owned by one user thread.\n\nAdd a check and rearm the timers if needed.\n\nBUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\nRead of size 2 at addr ffff88802f09b82a by task swapper/0/0\n\nCPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\n call_timer_fn+0x187/0x650 kernel/time/timer.c:1793\n expire_timers kernel/time/timer.c:1844 [inline]\n __run_timers kernel/time/timer.c:2418 [inline]\n __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430\n run_timer_base kernel/time/timer.c:2439 [inline]\n run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449\n handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n __do_softirq kernel/softirq.c:595 [inline]\n invoke_softirq kernel/softirq.c:435 [inline]\n __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:678\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049\n \u0026lt;/IRQ\u0026gt;(CVE-2025-21718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: do not force clear folio if buffer is referenced\n\nPatch series \u0026quot;nilfs2: protect busy buffer heads from being force-cleared\u0026quot;.\n\nThis series fixes the buffer head state inconsistency issues reported by\nsyzbot that occurs when the filesystem is corrupted and falls back to\nread-only, and the associated buffer head use-after-free issue.\n\n\nThis patch (of 2):\n\nSyzbot has reported that after nilfs2 detects filesystem corruption and\nfalls back to read-only, inconsistencies in the buffer state may occur.\n\nOne of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()\nto set a data or metadata buffer as dirty, but it detects that the buffer\nis not in the uptodate state:\n\n WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520\n fs/buffer.c:1177\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598\n nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73\n nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344\n nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe other is when nilfs_btree_propagate(), which propagates the dirty\nstate to the ancestor nodes of a b-tree that point to a dirty buffer,\ndetects that the origin buffer is not dirty, even though it should be:\n\n WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089\n nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345\n nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587\n nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006\n nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045\n nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]\n nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]\n nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115\n nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479\n nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]\n nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\n\nBoth of these issues are caused by the callbacks that handle the\npage/folio write requests, forcibly clear various states, including the\nworking state of the buffers they hold, at unexpected times when they\ndetect read-only fallback.\n\nFix these issues by checking if the buffer is referenced before clearing\nthe page/folio state, and skipping the clear if it is.(CVE-2025-21722)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: avoid UAF for reorder_work\n\nAlthough the previous patch can avoid ps and ps UAF for _do_serial, it\ncan not avoid potential UAF issue for reorder_work. This issue can\nhappen just as below:\n\ncrypto_request\t\t\tcrypto_request\t\tcrypto_del_alg\npadata_do_serial\n ...\n padata_reorder\n // processes all remaining\n // requests then breaks\n while (1) {\n if (!padata)\n break;\n ...\n }\n\n\t\t\t\tpadata_do_serial\n\t\t\t\t // new request added\n\t\t\t\t list_add\n // sees the new request\n queue_work(reorder_work)\n\t\t\t\t padata_reorder\n\t\t\t\t queue_work_on(squeue-\u0026gt;work)\n...\n\n\t\t\t\t\u0026lt;kworker context\u0026gt;\n\t\t\t\tpadata_serial_worker\n\t\t\t\t// completes new request,\n\t\t\t\t// no more outstanding\n\t\t\t\t// requests\n\n\t\t\t\t\t\t\tcrypto_del_alg\n\t\t\t\t\t\t\t // free pd\n\n\u0026lt;kworker context\u0026gt;\ninvoke_padata_reorder\n // UAF of pd\n\nTo avoid UAF for \u0026apos;reorder_work\u0026apos;, get \u0026apos;pd\u0026apos; ref before put \u0026apos;reorder_work\u0026apos;\ninto the \u0026apos;serial_wq\u0026apos; and put \u0026apos;pd\u0026apos; ref until the \u0026apos;serial_wq\u0026apos; finish.(CVE-2025-21726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0026apos;mdelay(10)\u0026apos; is added before calling \u0026apos;padata_find_next\u0026apos; in the\n\u0026apos;padata_reorder\u0026apos; function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u0026gt;pd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0026apos;while\u0026apos;, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0026apos;padata_find_next\u0026apos;, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0026apos;padata_free_shell\u0026apos; wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array\n\nThe loop that detects/populates cache information already has a bounds\ncheck on the array size but does not account for cache levels with\nseparate data/instructions cache. Fix this by incrementing the index\nfor any populated leaf (instead of any populated level).(CVE-2025-21785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvrf: use RCU protection in l3mdev_l3_out()\n\nl3mdev_l3_out() can be called without RCU being held:\n\nraw_sendmsg()\n ip_push_pending_frames()\n ip_send_skb()\n ip_local_out()\n __ip_local_out()\n l3mdev_ip_out()\n\nAdd rcu_read_lock() / rcu_read_unlock() pair to avoid\na potential UAF.(CVE-2025-21791)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()\n\nThe rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()\nmacro to request a needed resource. A string variable that lives on the\nstack is then used to store a dynamically computed resource name, which\nis then passed on as one of the macro arguments. This can lead to\nundefined behavior.\n\nDepending on the current contents of the memory, the manifestations of\nerrors may vary. One possible output may be as follows:\n\n $ cat /proc/iomem\n 30000000-37ffffff :\n 38000000-3fffffff :\n\nSometimes, garbage may appear after the colon.\n\nIn very rare cases, if no NULL-terminator is found in memory, the system\nmight crash because the string iterator will overrun which can lead to\naccess of unmapped memory above the stack.\n\nThus, fix this by replacing outbound_name with the name of the previously\nrequested resource. With the changes applied, the output will be as\nfollows:\n\n $ cat /proc/iomem\n 30000000-37ffffff : memory2\n 38000000-3fffffff : memory3\n\n[kwilczynski: commit log](CVE-2025-21804)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING\n\nhrtimers are migrated away from the dying CPU to any online target at\nthe CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers\nhandling tasks involved in the CPU hotplug forward progress.\n\nHowever wakeups can still be performed by the outgoing CPU after\nCPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being\narmed. Depending on several considerations (crystal ball power management\nbased election, earliest timer already enqueued, timer migration enabled or\nnot), the target may eventually be the current CPU even if offline. If that\nhappens, the timer is eventually ignored.\n\nThe most notable example is RCU which had to deal with each and every of\nthose wake-ups by deferring them to an online CPU, along with related\nworkarounds:\n\n_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)\n_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)\n_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)\n\nThe problem isn\u0026apos;t confined to RCU though as the stop machine kthread\n(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end\nof its work through cpu_stop_signal_done() and performs a wake up that\neventually arms the deadline server timer:\n\n WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0\n CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted\n Stopper: multi_cpu_stop+0x0/0x120 \u0026lt;- stop_machine_cpuslocked+0x66/0xc0\n RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n start_dl_timer\n enqueue_dl_entity\n dl_server_start\n enqueue_task_fair\n enqueue_task\n ttwu_do_activate\n try_to_wake_up\n complete\n cpu_stopper_thread\n\nInstead of providing yet another bandaid to work around the situation, fix\nit in the hrtimers infrastructure instead: always migrate away a timer to\nan online target whenever it is enqueued from an offline CPU.\n\nThis will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Drop unmanaged ELP metric worker\n\nThe ELP worker needs to calculate new metric values for all neighbors\n\u0026quot;reachable\u0026quot; over an interface. Some of the used metric sources require\nlocks which might need to sleep. This sleep is incompatible with the RCU\nlist iterator used for the recorded neighbors. The initial approach to work\naround of this problem was to queue another work item per neighbor and then\nrun this in a new context.\n\nEven when this solved the RCU vs might_sleep() conflict, it has a major\nproblems: Nothing was stopping the work item in case it is not needed\nanymore - for example because one of the related interfaces was removed or\nthe batman-adv module was unloaded - resulting in potential invalid memory\naccesses.\n\nDirectly canceling the metric worker also has various problems:\n\n* cancel_work_sync for a to-be-deactivated interface is called with\n rtnl_lock held. But the code in the ELP metric worker also tries to use\n rtnl_lock() - which will never return in this case. This also means that\n cancel_work_sync would never return because it is waiting for the worker\n to finish.\n* iterating over the neighbor list for the to-be-deactivated interface is\n currently done using the RCU specific methods. Which means that it is\n possible to miss items when iterating over it without the associated\n spinlock - a behaviour which is acceptable for a periodic metric check\n but not for a cleanup routine (which must \u0026quot;stop\u0026quot; all still running\n workers)\n\nThe better approch is to get rid of the per interface neighbor metric\nworker and handle everything in the interface worker. The original problems\nare solved by:\n\n* creating a list of neighbors which require new metric information inside\n the RCU protected context, gathering the metric according to the new list\n outside the RCU protected context\n* only use rcu_trylock inside metric gathering code to avoid a deadlock\n when the cancel_delayed_work_sync is called in the interface removal code\n (which is called with the rtnl_lock held)(CVE-2025-21823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: prevent opcode speculation\n\nsqe-\u0026gt;opcode is used for different tables, make sure we santitise it\nagainst speculations.(CVE-2025-21863)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuprobes: Reject the shared zeropage in uprobe_write_opcode()\n\nWe triggered the following crash in syzkaller tests:\n\n BUG: Bad page state in process syz.7.38 pfn:1eff3\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3\n flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)\n raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000\n raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000\n page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x32/0x50\n bad_page+0x69/0xf0\n free_unref_page_prepare+0x401/0x500\n free_unref_page+0x6d/0x1b0\n uprobe_write_opcode+0x460/0x8e0\n install_breakpoint.part.0+0x51/0x80\n register_for_each_vma+0x1d9/0x2b0\n __uprobe_register+0x245/0x300\n bpf_uprobe_multi_link_attach+0x29b/0x4f0\n link_create+0x1e2/0x280\n __sys_bpf+0x75f/0xac0\n __x64_sys_bpf+0x1a/0x30\n do_syscall_64+0x56/0x100\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\n BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1\n\nThe following syzkaller test case can be used to reproduce:\n\n r2 = creat(\u0026amp;(0x7f0000000000)=\u0026apos;./file0\\x00\u0026apos;, 0x8)\n write$nbd(r2, \u0026amp;(0x7f0000000580)=ANY=[], 0x10)\n r4 = openat(0xffffffffffffff9c, \u0026amp;(0x7f0000000040)=\u0026apos;./file0\\x00\u0026apos;, 0x42, 0x0)\n mmap$IORING_OFF_SQ_RING(\u0026amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)\n r5 = userfaultfd(0x80801)\n ioctl$UFFDIO_API(r5, 0xc018aa3f, \u0026amp;(0x7f0000000040)={0xaa, 0x20})\n r6 = userfaultfd(0x80801)\n ioctl$UFFDIO_API(r6, 0xc018aa3f, \u0026amp;(0x7f0000000140))\n ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, \u0026amp;(0x7f0000000100)={{\u0026amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})\n ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, \u0026amp;(0x7f0000000000)={{\u0026amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})\n r7 = bpf$PROG_LOAD(0x5, \u0026amp;(0x7f0000000140)={0x2, 0x3, \u0026amp;(0x7f0000000200)=ANY=[@ANYBLOB=\u0026quot;1800000000120000000000000000000095\u0026quot;], \u0026amp;(0x7f0000000000)=\u0026apos;GPL\\x00\u0026apos;, 0x7, 0x0, 0x0, 0x0, 0x0, \u0026apos;\\x00\u0026apos;, 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)\n bpf$BPF_LINK_CREATE_XDP(0x1c, \u0026amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={\u0026amp;(0x7f0000000080)=\u0026apos;./file0\\x00\u0026apos;, \u0026amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)\n\nThe cause is that zero pfn is set to the PTE without increasing the RSS\ncount in mfill_atomic_pte_zeropage() and the refcount of zero folio does\nnot increase accordingly. Then, the operation on the same pfn is performed\nin uprobe_write_opcode()-\u0026gt;__replace_page() to unconditional decrease the\nRSS count and old_folio\u0026apos;s refcount.\n\nTherefore, two bugs are introduced:\n\n 1. The RSS count is incorrect, when process exit, the check_mm() report\n error \u0026quot;Bad rss-count\u0026quot;.\n\n 2. The reserved folio (zero folio) is freed when folio-\u0026gt;refcount is zero,\n then free_pages_prepare-\u0026gt;free_page_is_bad() report error\n \u0026quot;Bad page state\u0026quot;.\n\nThere is more, the following warning could also theoretically be triggered:\n\n __replace_page()\n -\u0026gt; ...\n -\u0026gt; folio_remove_rmap_pte()\n -\u0026gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)\n\nConsidering that uprobe hit on the zero folio is a very rare case, just\nreject zero old folio immediately after get_user_page_vma_remote().\n\n[ mingo: Cleaned up the changelog ](CVE-2025-21881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\novl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up\n\nThe issue was caused by dput(upper) being called before\novl_dentry_update_reval(), while upper-\u0026gt;d_flags was still\naccessed in ovl_dentry_remote().\n\nMove dput(upper) after its last use to prevent use-after-free.\n\nBUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\nBUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc3/0x620 mm/kasan/report.c:488\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\n ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n ovl_link_up fs/overlayfs/copy_up.c:610 [inline]\n ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170\n ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223\n ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136\n vfs_rename+0xf84/0x20a0 fs/namei.c:4893\n...\n \u0026lt;/TASK\u0026gt;(CVE-2025-21887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpio: aggregator: protect driver attr handlers against module unload\n\nBoth new_device_store and delete_device_store touch module global\nresources (e.g. gpio_aggregator_lock). To prevent race conditions with\nmodule unload, a reference needs to be held.\n\nAdd try_module_get() in these handlers.\n\nFor new_device_store, this eliminates what appears to be the most dangerous\nscenario: if an id is allocated from gpio_aggregator_idr but\nplatform_device_register has not yet been called or completed, a concurrent\nmodule unload could fail to unregister/delete the device, leaving behind a\ndangling platform device/GPIO forwarder. This can result in various issues.\nThe following simple reproducer demonstrates these problems:\n\n #!/bin/bash\n while :; do\n # note: whether \u0026apos;gpiochip0 0\u0026apos; exists or not does not matter.\n echo \u0026apos;gpiochip0 0\u0026apos; \u0026gt; /sys/bus/platform/drivers/gpio-aggregator/new_device\n done \u0026amp;\n while :; do\n modprobe gpio-aggregator\n modprobe -r gpio-aggregator\n done \u0026amp;\n wait\n\n Starting with the following warning, several kinds of warnings will appear\n and the system may become unstable:\n\n ------------[ cut here ]------------\n list_del corruption, ffff888103e2e980-\u0026gt;next is LIST_POISON1 (dead000000000100)\n WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120\n [...]\n RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __list_del_entry_valid_or_report+0xa3/0x120\n ? __warn.cold+0x93/0xf2\n ? __list_del_entry_valid_or_report+0xa3/0x120\n ? report_bug+0xe6/0x170\n ? __irq_work_queue_local+0x39/0xe0\n ? handle_bug+0x58/0x90\n ? exc_invalid_op+0x13/0x60\n ? asm_exc_invalid_op+0x16/0x20\n ? __list_del_entry_valid_or_report+0xa3/0x120\n gpiod_remove_lookup_table+0x22/0x60\n new_device_store+0x315/0x350 [gpio_aggregator]\n kernfs_fop_write_iter+0x137/0x1f0\n vfs_write+0x262/0x430\n ksys_write+0x60/0xd0\n do_syscall_64+0x6c/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [...]\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---(CVE-2025-21943)",
"id": "OESA-2025-1409",
"modified": "2026-08-06T11:08:30Z",
"published": "2025-04-11T11:08:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1409"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47660"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49443"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49513"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49553"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21718"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21816"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21943"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47660",
"CVE-2022-49443",
"CVE-2022-49513",
"CVE-2022-49553",
"CVE-2023-53001",
"CVE-2024-56642",
"CVE-2024-56664",
"CVE-2024-57951",
"CVE-2024-58055",
"CVE-2025-21715",
"CVE-2025-21718",
"CVE-2025-21722",
"CVE-2025-21726",
"CVE-2025-21727",
"CVE-2025-21785",
"CVE-2025-21791",
"CVE-2025-21804",
"CVE-2025-21816",
"CVE-2025-21823",
"CVE-2025-21863",
"CVE-2025-21881",
"CVE-2025-21887",
"CVE-2025-21943"
]
}
oesa-2025-1410
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix some memory leaks in an error handling path of 'log_replay()'
All error handling paths lead to 'out' where many resources are freed.
Do it as well here instead of a direct return, otherwise 'log', 'ra' and 'log->one_page_buf' (at least) will leak.(CVE-2021-47660)
In the Linux kernel, the following vulnerability has been resolved:
list: fix a data-race around ep->rdllist
ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing.
Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless ep_events_available(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last ep_events_available() lockless.
BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait
write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0xffff88810480c7d0 -> 0xffff888103c15098
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: governor: Use kobject release() method to free dbs_data
The struct dbs_data embeds a struct gov_attr_set and the struct gov_attr_set embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreq_dbs_data_release() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate BOOT sectors_per_clusters
When the NTFS BOOT sectors_per_clusters field is > 0x80, it represents a shift value. Make sure that the shift value is not too large before using it (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.
This prevents negative shift values and shift values that are larger than the field size.
Prevents this UBSAN error:
UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16 shift exponent -192 is negative(CVE-2022-49553)
In the Linux kernel, the following vulnerability has been resolved:
drm/drm_vma_manager: Add drm_vma_node_allow_once()
Currently there is no easy way for a drm driver to safely check and allow drm_vma_offset_node for a drm file just once. Allow drm drivers to call non-refcounted version of drm_vma_node_allow() so that a driver doesn't need to keep track of each drm_vma_node_allow() to call subsequent drm_vma_node_revoke() to prevent memory leak.(CVE-2023-53001)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free of kernel socket in cleanup_bearer().
syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1]
When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer().
tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free.
Let's move the decrement after releasing the socket in cleanup_bearer().
[0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830
[1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer(CVE-2024-56642)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix race between element replace and close()
Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element:
// set map[0] = s0 map_update_elem(map, 0, s0)
// drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk)
Then close(map) enqueues bpf_map_free_deferred, which finally calls sock_map_free(). This results in some refcount_t warnings along with a KASAN splat [1].
Fix __sock_map_delete(), do not allow sock_map_unref() on elements that may have been replaced.
[1]: BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330 Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063
CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred Call Trace: <TASK> dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30
The bu ---truncated---(CVE-2024-56664)
In the Linux kernel, the following vulnerability has been resolved:
hrtimers: Handle CPU state correctly on hotplug
Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to CPUHP_ONLINE:
Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set to 1 throughout. However, during a CPU unplug operation, the tick and the clockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online state, for instance CFS incorrectly assumes that the hrtick is already active, and the chance of the clockevent device to transition to oneshot mode is also lost forever for the CPU, unless it goes back to a lower state than CPUHP_HRTIMERS_PREPARE once.
This round-trip reveals another issue; cpu_base.online is not set to 1 after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().
Aside of that, the bulk of the per CPU state is not reset either, which means there are dangling pointers in the worst case.
Address this by adding a corresponding startup() callback, which resets the stale per CPU state and sets the online flag.
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_tcm: Don't free command immediately
Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.(CVE-2024-58055)
In the Linux kernel, the following vulnerability has been resolved:
net: davicom: fix UAF in dm9000_drv_remove
dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.
This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").
This bug is detected by our static analysis tool.(CVE-2025-21715)
In the Linux kernel, the following vulnerability has been resolved:
net: rose: fix timer races against user threads
Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread.
Add a check and rearm the timers if needed.
BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ>(CVE-2025-21718)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: do not force clear folio if buffer is referenced
Patch series "nilfs2: protect busy buffer heads from being force-cleared".
This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue.
This patch (of 2):
Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur.
One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state:
WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be:
WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>
Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback.
Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.(CVE-2025-21722)
In the Linux kernel, the following vulnerability has been resolved:
padata: avoid UAF for reorder_work
Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below:
crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }
padata_do_serial
// new request added
list_add
// sees the new request
queue_work(reorder_work)
padata_reorder
queue_work_on(squeue->work)
...
<kworker context>
padata_serial_worker
// completes new request,
// no more outstanding
// requests
crypto_del_alg
// free pd
<kworker context> invoke_padata_reorder // UAF of pd
To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.(CVE-2025-21726)
In the Linux kernel, the following vulnerability has been resolved:
padata: fix UAF in padata_reorder
A bug was found when run ltp test:
BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206
CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0
If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01).
This can be explained as bellow:
pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF }
In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF.
As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish.
[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)
In the Linux kernel, the following vulnerability has been resolved:
arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array
The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).(CVE-2025-21785)
In the Linux kernel, the following vulnerability has been resolved:
vrf: use RCU protection in l3mdev_l3_out()
l3mdev_l3_out() can be called without RCU being held:
raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out()
Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.(CVE-2025-21791)
In the Linux kernel, the following vulnerability has been resolved:
PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()
The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior.
Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows:
$ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :
Sometimes, garbage may appear after the colon.
In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack.
Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows:
$ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3
In the Linux kernel, the following vulnerability has been resolved:
hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING
hrtimers are migrated away from the dying CPU to any online target at the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers handling tasks involved in the CPU hotplug forward progress.
However wakeups can still be performed by the outgoing CPU after CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being armed. Depending on several considerations (crystal ball power management based election, earliest timer already enqueued, timer migration enabled or not), the target may eventually be the current CPU even if offline. If that happens, the timer is eventually ignored.
The most notable example is RCU which had to deal with each and every of those wake-ups by deferring them to an online CPU, along with related workarounds:
_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying) _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU) _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)
The problem isn't confined to RCU though as the stop machine kthread (which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end of its work through cpu_stop_signal_done() and performs a wake up that eventually arms the deadline server timer:
WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace: <TASK> start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_thread
Instead of providing yet another bandaid to work around the situation, fix it in the hrtimers infrastructure instead: always migrate away a timer to an online target whenever it is enqueued from an offline CPU.
This will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Drop unmanaged ELP metric worker
The ELP worker needs to calculate new metric values for all neighbors "reachable" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context.
Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses.
Directly canceling the metric worker also has various problems:
- cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish.
- iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)
The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by:
- creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context
- only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)(CVE-2025-21823)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: prevent opcode speculation
sqe->opcode is used for different tables, make sure we santitise it against speculations.(CVE-2025-21863)
In the Linux kernel, the following vulnerability has been resolved:
uprobes: Reject the shared zeropage in uprobe_write_opcode()
We triggered the following crash in syzkaller tests:
BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint.part.0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0 __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280 __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2
BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1
The following syzkaller test case can be used to reproduce:
r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)
The cause is that zero pfn is set to the PTE without increasing the RSS count in mfill_atomic_pte_zeropage() and the refcount of zero folio does not increase accordingly. Then, the operation on the same pfn is performed in uprobe_write_opcode()->__replace_page() to unconditional decrease the RSS count and old_folio's refcount.
Therefore, two bugs are introduced:
-
The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count".
-
The reserved folio (zero folio) is freed when folio->refcount is zero, then free_pages_prepare->free_page_is_bad() report error "Bad page state".
There is more, the following warning could also theoretically be triggered:
__replace_page() -> ... -> folio_remove_rmap_pte() -> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)
Considering that uprobe hit on the zero folio is a very rare case, just reject zero old folio immediately after get_user_page_vma_remote().
mingo: Cleaned up the changelog
In the Linux kernel, the following vulnerability has been resolved:
ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up
The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote().
Move dput(upper) after its last use to prevent use-after-free.
BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167
Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... </TASK>(CVE-2025-21887)
In the Linux kernel, the following vulnerability has been resolved:
gpio: aggregator: protect driver attr handlers against module unload
Both new_device_store and delete_device_store touch module global resources (e.g. gpio_aggregator_lock). To prevent race conditions with module unload, a reference needs to be held.
Add try_module_get() in these handlers.
For new_device_store, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems:
#!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait
Starting with the following warning, several kinds of warnings will appear and the system may become unstable:
------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: <TASK> ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]---(CVE-2025-21943)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"perf-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-259.0.0.162.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"perf-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-259.0.0.162.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix some memory leaks in an error handling path of \u0026apos;log_replay()\u0026apos;\n\nAll error handling paths lead to \u0026apos;out\u0026apos; where many resources are freed.\n\nDo it as well here instead of a direct return, otherwise \u0026apos;log\u0026apos;, \u0026apos;ra\u0026apos; and\n\u0026apos;log-\u0026gt;one_page_buf\u0026apos; (at least) will leak.(CVE-2021-47660)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlist: fix a data-race around ep-\u0026gt;rdllist\n\nep_poll() first calls ep_events_available() with no lock held and checks\nif ep-\u0026gt;rdllist is empty by list_empty_careful(), which reads\nrdllist-\u0026gt;prev. Thus all accesses to it need some protection to avoid\nstore/load-tearing.\n\nNote INIT_LIST_HEAD_RCU() already has the annotation for both prev\nand next.\n\nCommit bf3b9f6372c4 (\u0026quot;epoll: Add busy poll support to epoll with socket\nfds.\u0026quot;) added the first lockless ep_events_available(), and commit\nc5a282e9635e (\u0026quot;fs/epoll: reduce the scope of wq lock in epoll_wait()\u0026quot;)\nmade some ep_events_available() calls lockless and added single call under\na lock, finally commit e59d3c64cba6 (\u0026quot;epoll: eliminate unnecessary lock\nfor zero timeout\u0026quot;) made the last ep_events_available() lockless.\n\nBUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait\n\nwrite to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:\n INIT_LIST_HEAD include/linux/list.h:38 [inline]\n list_splice_init include/linux/list.h:492 [inline]\n ep_start_scan fs/eventpoll.c:622 [inline]\n ep_send_events fs/eventpoll.c:1656 [inline]\n ep_poll fs/eventpoll.c:1806 [inline]\n do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nread to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:\n list_empty_careful include/linux/list.h:329 [inline]\n ep_events_available fs/eventpoll.c:381 [inline]\n ep_poll fs/eventpoll.c:1797 [inline]\n do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nvalue changed: 0xffff88810480c7d0 -\u0026gt; 0xffff888103c15098\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: governor: Use kobject release() method to free dbs_data\n\nThe struct dbs_data embeds a struct gov_attr_set and\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\na release() method and we can\u0026apos;t use kfree() to free it directly,\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\nthe kobject::release() method. This fixes the calltrace like below:\n\n ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\n WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n Modules linked in:\n CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\n Hardware name: Marvell OcteonTX CN96XX board (DT)\n pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : debug_print_object+0xb8/0x100\n lr : debug_print_object+0xb8/0x100\n sp : ffff80001dfcf9a0\n x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\n x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\n x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\n x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\n x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\n x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\n x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\n x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\n x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\n Call trace:\n debug_print_object+0xb8/0x100\n __debug_check_no_obj_freed+0x1d0/0x25c\n debug_check_no_obj_freed+0x24/0xa0\n kfree+0x11c/0x440\n cpufreq_dbs_governor_exit+0xa8/0xac\n cpufreq_exit_governor+0x44/0x90\n cpufreq_set_policy+0x29c/0x570\n store_scaling_governor+0x110/0x154\n store+0xb0/0xe0\n sysfs_kf_write+0x58/0x84\n kernfs_fop_write_iter+0x12c/0x1c0\n new_sync_write+0xf0/0x18c\n vfs_write+0x1cc/0x220\n ksys_write+0x74/0x100\n __arm64_sys_write+0x28/0x3c\n invoke_syscall.constprop.0+0x58/0xf0\n do_el0_svc+0x70/0x170\n el0_svc+0x54/0x190\n el0t_64_sync_handler+0xa4/0x130\n el0t_64_sync+0x1a0/0x1a4\n irq event stamp: 189006\n hardirqs last enabled at (189005): [\u0026lt;ffff8000080849d0\u0026gt;] finish_task_switch.isra.0+0xe0/0x2c0\n hardirqs last disabled at (189006): [\u0026lt;ffff8000090667a4\u0026gt;] el1_dbg+0x24/0xa0\n softirqs last enabled at (188966): [\u0026lt;ffff8000080106d0\u0026gt;] __do_softirq+0x4b0/0x6a0\n softirqs last disabled at (188957): [\u0026lt;ffff80000804a618\u0026gt;] __irq_exit_rcu+0x108/0x1a4\n\n[ rjw: Because can be freed by the gov_attr_set_put() in\n cpufreq_dbs_governor_exit() now, it is also necessary to put the\n invocation of the governor -\u0026gt;exit() callback into the new\n cpufreq_dbs_data_release() function. ](CVE-2022-49513)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: validate BOOT sectors_per_clusters\n\nWhen the NTFS BOOT sectors_per_clusters field is \u0026gt; 0x80, it represents a\nshift value. Make sure that the shift value is not too large before using\nit (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.\n\nThis prevents negative shift values and shift values that are larger than\nthe field size.\n\nPrevents this UBSAN error:\n\n UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16\n shift exponent -192 is negative(CVE-2022-49553)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_vma_manager: Add drm_vma_node_allow_once()\n\nCurrently there is no easy way for a drm driver to safely check and allow\ndrm_vma_offset_node for a drm file just once. Allow drm drivers to call\nnon-refcounted version of drm_vma_node_allow() so that a driver doesn\u0026apos;t\nneed to keep track of each drm_vma_node_allow() to call subsequent\ndrm_vma_node_revoke() to prevent memory leak.(CVE-2023-53001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free of kernel socket in cleanup_bearer().\n\nsyzkaller reported a use-after-free of UDP kernel socket\nin cleanup_bearer() without repro. [0][1]\n\nWhen bearer_disable() calls tipc_udp_disable(), cleanup\nof the UDP kernel socket is deferred by work calling\ncleanup_bearer().\n\ntipc_exit_net() waits for such works to finish by checking\ntipc_net(net)-\u0026gt;wq_count. However, the work decrements the\ncount too early before releasing the kernel socket,\nunblocking cleanup_net() and resulting in use-after-free.\n\nLet\u0026apos;s move the decrement after releasing the socket in\ncleanup_bearer().\n\n[0]:\nref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at\n sk_alloc+0x438/0x608\n inet_create+0x4c8/0xcb0\n __sock_create+0x350/0x6b8\n sock_create_kern+0x58/0x78\n udp_sock_create4+0x68/0x398\n udp_sock_create+0x88/0xc8\n tipc_udp_enable+0x5e8/0x848\n __tipc_nl_bearer_enable+0x84c/0xed8\n tipc_nl_bearer_enable+0x38/0x60\n genl_family_rcv_msg_doit+0x170/0x248\n genl_rcv_msg+0x400/0x5b0\n netlink_rcv_skb+0x1dc/0x398\n genl_rcv+0x44/0x68\n netlink_unicast+0x678/0x8b0\n netlink_sendmsg+0x5e4/0x898\n ____sys_sendmsg+0x500/0x830\n\n[1]:\nBUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]\nBUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n udp_hashslot include/net/udp.h:85 [inline]\n udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n sk_common_release+0xaf/0x3f0 net/core/sock.c:3820\n inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437\n inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489\n __sock_release net/socket.c:658 [inline]\n sock_release+0xa0/0x210 net/socket.c:686\n cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nUninit was created at:\n slab_free_hook mm/slub.c:2269 [inline]\n slab_free mm/slub.c:4580 [inline]\n kmem_cache_free+0x207/0xc40 mm/slub.c:4682\n net_free net/core/net_namespace.c:454 [inline]\n cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nCPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: events cleanup_bearer(CVE-2024-56642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix race between element replace and close()\n\nElement replace (with a socket different from the one stored) may race\nwith socket\u0026apos;s close() link popping \u0026amp; unlinking. __sock_map_delete()\nunconditionally unrefs the (wrong) element:\n\n// set map[0] = s0\nmap_update_elem(map, 0, s0)\n\n// drop fd of s0\nclose(s0)\n sock_map_close()\n lock_sock(sk) (s0!)\n sock_map_remove_links(sk)\n link = sk_psock_link_pop()\n sock_map_unlink(sk, link)\n sock_map_delete_from_link\n // replace map[0] with s1\n map_update_elem(map, 0, s1)\n sock_map_update_elem\n (s1!) lock_sock(sk)\n sock_map_update_common\n psock = sk_psock(sk)\n spin_lock(\u0026amp;stab-\u0026gt;lock)\n osk = stab-\u0026gt;sks[idx]\n sock_map_add_link(..., \u0026amp;stab-\u0026gt;sks[idx])\n sock_map_unref(osk, \u0026amp;stab-\u0026gt;sks[idx])\n psock = sk_psock(osk)\n sk_psock_put(sk, psock)\n if (refcount_dec_and_test(\u0026amp;psock))\n sk_psock_drop(sk, psock)\n spin_unlock(\u0026amp;stab-\u0026gt;lock)\n unlock_sock(sk)\n __sock_map_delete\n spin_lock(\u0026amp;stab-\u0026gt;lock)\n sk = *psk // s1 replaced s0; sk == s1\n if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch\n sk = xchg(psk, NULL)\n if (sk)\n sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle\n psock = sk_psock(sk)\n sk_psock_put(sk, psock)\n if (refcount_dec_and_test())\n sk_psock_drop(sk, psock)\n spin_unlock(\u0026amp;stab-\u0026gt;lock)\n release_sock(sk)\n\nThen close(map) enqueues bpf_map_free_deferred, which finally calls\nsock_map_free(). This results in some refcount_t warnings along with\na KASAN splat [1].\n\nFix __sock_map_delete(), do not allow sock_map_unref() on elements that\nmay have been replaced.\n\n[1]:\nBUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330\nWrite of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063\n\nCPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\nWorkqueue: events_unbound bpf_map_free_deferred\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x68/0x90\n print_report+0x174/0x4f6\n kasan_report+0xb9/0x190\n kasan_check_range+0x10f/0x1e0\n sock_map_free+0x10e/0x330\n bpf_map_free_deferred+0x173/0x320\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 1202:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n __kasan_slab_alloc+0x85/0x90\n kmem_cache_alloc_noprof+0x131/0x450\n sk_prot_alloc+0x5b/0x220\n sk_alloc+0x2c/0x870\n unix_create1+0x88/0x8a0\n unix_create+0xc5/0x180\n __sock_create+0x241/0x650\n __sys_socketpair+0x1ce/0x420\n __x64_sys_socketpair+0x92/0x100\n do_syscall_64+0x93/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 46:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x37/0x60\n __kasan_slab_free+0x4b/0x70\n kmem_cache_free+0x1a1/0x590\n __sk_destruct+0x388/0x5a0\n sk_psock_destroy+0x73e/0xa50\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n\nThe bu\n---truncated---(CVE-2024-56664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Handle CPU state correctly on hotplug\n\nConsider a scenario where a CPU transitions from CPUHP_ONLINE to halfway\nthrough a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to\nCPUHP_ONLINE:\n\nSince hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set\nto 1 throughout. However, during a CPU unplug operation, the tick and the\nclockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online\nstate, for instance CFS incorrectly assumes that the hrtick is already\nactive, and the chance of the clockevent device to transition to oneshot\nmode is also lost forever for the CPU, unless it goes back to a lower state\nthan CPUHP_HRTIMERS_PREPARE once.\n\nThis round-trip reveals another issue; cpu_base.online is not set to 1\nafter the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().\n\nAside of that, the bulk of the per CPU state is not reset either, which\nmeans there are dangling pointers in the worst case.\n\nAddress this by adding a corresponding startup() callback, which resets the\nstale per CPU state and sets the online flag.\n\n[ tglx: Make the new callback unconditionally available, remove the online\n \tmodification in the prepare() callback and clear the remaining\n \tstate in the starting callback instead of the prepare callback ](CVE-2024-57951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_tcm: Don\u0026apos;t free command immediately\n\nDon\u0026apos;t prematurely free the command. Wait for the status completion of\nthe sense status. It can be freed then. Otherwise we will double-free\nthe command.(CVE-2024-58055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: davicom: fix UAF in dm9000_drv_remove\n\ndm is netdev private data and it cannot be\nused after free_netdev() call. Using dm after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.\n\nThis is similar to the issue fixed in commit\nad297cd2db89 (\u0026quot;net: qcom/emac: fix UAF in emac_remove\u0026quot;).\n\nThis bug is detected by our static analysis tool.(CVE-2025-21715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: rose: fix timer races against user threads\n\nRose timers only acquire the socket spinlock, without\nchecking if the socket is owned by one user thread.\n\nAdd a check and rearm the timers if needed.\n\nBUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\nRead of size 2 at addr ffff88802f09b82a by task swapper/0/0\n\nCPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\n call_timer_fn+0x187/0x650 kernel/time/timer.c:1793\n expire_timers kernel/time/timer.c:1844 [inline]\n __run_timers kernel/time/timer.c:2418 [inline]\n __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430\n run_timer_base kernel/time/timer.c:2439 [inline]\n run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449\n handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n __do_softirq kernel/softirq.c:595 [inline]\n invoke_softirq kernel/softirq.c:435 [inline]\n __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:678\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049\n \u0026lt;/IRQ\u0026gt;(CVE-2025-21718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: do not force clear folio if buffer is referenced\n\nPatch series \u0026quot;nilfs2: protect busy buffer heads from being force-cleared\u0026quot;.\n\nThis series fixes the buffer head state inconsistency issues reported by\nsyzbot that occurs when the filesystem is corrupted and falls back to\nread-only, and the associated buffer head use-after-free issue.\n\n\nThis patch (of 2):\n\nSyzbot has reported that after nilfs2 detects filesystem corruption and\nfalls back to read-only, inconsistencies in the buffer state may occur.\n\nOne of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()\nto set a data or metadata buffer as dirty, but it detects that the buffer\nis not in the uptodate state:\n\n WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520\n fs/buffer.c:1177\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598\n nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73\n nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344\n nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe other is when nilfs_btree_propagate(), which propagates the dirty\nstate to the ancestor nodes of a b-tree that point to a dirty buffer,\ndetects that the origin buffer is not dirty, even though it should be:\n\n WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089\n nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345\n nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587\n nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006\n nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045\n nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]\n nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]\n nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115\n nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479\n nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]\n nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\n\nBoth of these issues are caused by the callbacks that handle the\npage/folio write requests, forcibly clear various states, including the\nworking state of the buffers they hold, at unexpected times when they\ndetect read-only fallback.\n\nFix these issues by checking if the buffer is referenced before clearing\nthe page/folio state, and skipping the clear if it is.(CVE-2025-21722)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: avoid UAF for reorder_work\n\nAlthough the previous patch can avoid ps and ps UAF for _do_serial, it\ncan not avoid potential UAF issue for reorder_work. This issue can\nhappen just as below:\n\ncrypto_request\t\t\tcrypto_request\t\tcrypto_del_alg\npadata_do_serial\n ...\n padata_reorder\n // processes all remaining\n // requests then breaks\n while (1) {\n if (!padata)\n break;\n ...\n }\n\n\t\t\t\tpadata_do_serial\n\t\t\t\t // new request added\n\t\t\t\t list_add\n // sees the new request\n queue_work(reorder_work)\n\t\t\t\t padata_reorder\n\t\t\t\t queue_work_on(squeue-\u0026gt;work)\n...\n\n\t\t\t\t\u0026lt;kworker context\u0026gt;\n\t\t\t\tpadata_serial_worker\n\t\t\t\t// completes new request,\n\t\t\t\t// no more outstanding\n\t\t\t\t// requests\n\n\t\t\t\t\t\t\tcrypto_del_alg\n\t\t\t\t\t\t\t // free pd\n\n\u0026lt;kworker context\u0026gt;\ninvoke_padata_reorder\n // UAF of pd\n\nTo avoid UAF for \u0026apos;reorder_work\u0026apos;, get \u0026apos;pd\u0026apos; ref before put \u0026apos;reorder_work\u0026apos;\ninto the \u0026apos;serial_wq\u0026apos; and put \u0026apos;pd\u0026apos; ref until the \u0026apos;serial_wq\u0026apos; finish.(CVE-2025-21726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0026apos;mdelay(10)\u0026apos; is added before calling \u0026apos;padata_find_next\u0026apos; in the\n\u0026apos;padata_reorder\u0026apos; function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u0026gt;pd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0026apos;while\u0026apos;, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0026apos;padata_find_next\u0026apos;, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0026apos;padata_free_shell\u0026apos; wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array\n\nThe loop that detects/populates cache information already has a bounds\ncheck on the array size but does not account for cache levels with\nseparate data/instructions cache. Fix this by incrementing the index\nfor any populated leaf (instead of any populated level).(CVE-2025-21785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvrf: use RCU protection in l3mdev_l3_out()\n\nl3mdev_l3_out() can be called without RCU being held:\n\nraw_sendmsg()\n ip_push_pending_frames()\n ip_send_skb()\n ip_local_out()\n __ip_local_out()\n l3mdev_ip_out()\n\nAdd rcu_read_lock() / rcu_read_unlock() pair to avoid\na potential UAF.(CVE-2025-21791)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()\n\nThe rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()\nmacro to request a needed resource. A string variable that lives on the\nstack is then used to store a dynamically computed resource name, which\nis then passed on as one of the macro arguments. This can lead to\nundefined behavior.\n\nDepending on the current contents of the memory, the manifestations of\nerrors may vary. One possible output may be as follows:\n\n $ cat /proc/iomem\n 30000000-37ffffff :\n 38000000-3fffffff :\n\nSometimes, garbage may appear after the colon.\n\nIn very rare cases, if no NULL-terminator is found in memory, the system\nmight crash because the string iterator will overrun which can lead to\naccess of unmapped memory above the stack.\n\nThus, fix this by replacing outbound_name with the name of the previously\nrequested resource. With the changes applied, the output will be as\nfollows:\n\n $ cat /proc/iomem\n 30000000-37ffffff : memory2\n 38000000-3fffffff : memory3\n\n[kwilczynski: commit log](CVE-2025-21804)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING\n\nhrtimers are migrated away from the dying CPU to any online target at\nthe CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers\nhandling tasks involved in the CPU hotplug forward progress.\n\nHowever wakeups can still be performed by the outgoing CPU after\nCPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being\narmed. Depending on several considerations (crystal ball power management\nbased election, earliest timer already enqueued, timer migration enabled or\nnot), the target may eventually be the current CPU even if offline. If that\nhappens, the timer is eventually ignored.\n\nThe most notable example is RCU which had to deal with each and every of\nthose wake-ups by deferring them to an online CPU, along with related\nworkarounds:\n\n_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)\n_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)\n_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)\n\nThe problem isn\u0026apos;t confined to RCU though as the stop machine kthread\n(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end\nof its work through cpu_stop_signal_done() and performs a wake up that\neventually arms the deadline server timer:\n\n WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0\n CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted\n Stopper: multi_cpu_stop+0x0/0x120 \u0026lt;- stop_machine_cpuslocked+0x66/0xc0\n RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n start_dl_timer\n enqueue_dl_entity\n dl_server_start\n enqueue_task_fair\n enqueue_task\n ttwu_do_activate\n try_to_wake_up\n complete\n cpu_stopper_thread\n\nInstead of providing yet another bandaid to work around the situation, fix\nit in the hrtimers infrastructure instead: always migrate away a timer to\nan online target whenever it is enqueued from an offline CPU.\n\nThis will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Drop unmanaged ELP metric worker\n\nThe ELP worker needs to calculate new metric values for all neighbors\n\u0026quot;reachable\u0026quot; over an interface. Some of the used metric sources require\nlocks which might need to sleep. This sleep is incompatible with the RCU\nlist iterator used for the recorded neighbors. The initial approach to work\naround of this problem was to queue another work item per neighbor and then\nrun this in a new context.\n\nEven when this solved the RCU vs might_sleep() conflict, it has a major\nproblems: Nothing was stopping the work item in case it is not needed\nanymore - for example because one of the related interfaces was removed or\nthe batman-adv module was unloaded - resulting in potential invalid memory\naccesses.\n\nDirectly canceling the metric worker also has various problems:\n\n* cancel_work_sync for a to-be-deactivated interface is called with\n rtnl_lock held. But the code in the ELP metric worker also tries to use\n rtnl_lock() - which will never return in this case. This also means that\n cancel_work_sync would never return because it is waiting for the worker\n to finish.\n* iterating over the neighbor list for the to-be-deactivated interface is\n currently done using the RCU specific methods. Which means that it is\n possible to miss items when iterating over it without the associated\n spinlock - a behaviour which is acceptable for a periodic metric check\n but not for a cleanup routine (which must \u0026quot;stop\u0026quot; all still running\n workers)\n\nThe better approch is to get rid of the per interface neighbor metric\nworker and handle everything in the interface worker. The original problems\nare solved by:\n\n* creating a list of neighbors which require new metric information inside\n the RCU protected context, gathering the metric according to the new list\n outside the RCU protected context\n* only use rcu_trylock inside metric gathering code to avoid a deadlock\n when the cancel_delayed_work_sync is called in the interface removal code\n (which is called with the rtnl_lock held)(CVE-2025-21823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: prevent opcode speculation\n\nsqe-\u0026gt;opcode is used for different tables, make sure we santitise it\nagainst speculations.(CVE-2025-21863)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuprobes: Reject the shared zeropage in uprobe_write_opcode()\n\nWe triggered the following crash in syzkaller tests:\n\n BUG: Bad page state in process syz.7.38 pfn:1eff3\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3\n flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)\n raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000\n raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000\n page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x32/0x50\n bad_page+0x69/0xf0\n free_unref_page_prepare+0x401/0x500\n free_unref_page+0x6d/0x1b0\n uprobe_write_opcode+0x460/0x8e0\n install_breakpoint.part.0+0x51/0x80\n register_for_each_vma+0x1d9/0x2b0\n __uprobe_register+0x245/0x300\n bpf_uprobe_multi_link_attach+0x29b/0x4f0\n link_create+0x1e2/0x280\n __sys_bpf+0x75f/0xac0\n __x64_sys_bpf+0x1a/0x30\n do_syscall_64+0x56/0x100\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\n BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1\n\nThe following syzkaller test case can be used to reproduce:\n\n r2 = creat(\u0026amp;(0x7f0000000000)=\u0026apos;./file0\\x00\u0026apos;, 0x8)\n write$nbd(r2, \u0026amp;(0x7f0000000580)=ANY=[], 0x10)\n r4 = openat(0xffffffffffffff9c, \u0026amp;(0x7f0000000040)=\u0026apos;./file0\\x00\u0026apos;, 0x42, 0x0)\n mmap$IORING_OFF_SQ_RING(\u0026amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)\n r5 = userfaultfd(0x80801)\n ioctl$UFFDIO_API(r5, 0xc018aa3f, \u0026amp;(0x7f0000000040)={0xaa, 0x20})\n r6 = userfaultfd(0x80801)\n ioctl$UFFDIO_API(r6, 0xc018aa3f, \u0026amp;(0x7f0000000140))\n ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, \u0026amp;(0x7f0000000100)={{\u0026amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})\n ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, \u0026amp;(0x7f0000000000)={{\u0026amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})\n r7 = bpf$PROG_LOAD(0x5, \u0026amp;(0x7f0000000140)={0x2, 0x3, \u0026amp;(0x7f0000000200)=ANY=[@ANYBLOB=\u0026quot;1800000000120000000000000000000095\u0026quot;], \u0026amp;(0x7f0000000000)=\u0026apos;GPL\\x00\u0026apos;, 0x7, 0x0, 0x0, 0x0, 0x0, \u0026apos;\\x00\u0026apos;, 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)\n bpf$BPF_LINK_CREATE_XDP(0x1c, \u0026amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={\u0026amp;(0x7f0000000080)=\u0026apos;./file0\\x00\u0026apos;, \u0026amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)\n\nThe cause is that zero pfn is set to the PTE without increasing the RSS\ncount in mfill_atomic_pte_zeropage() and the refcount of zero folio does\nnot increase accordingly. Then, the operation on the same pfn is performed\nin uprobe_write_opcode()-\u0026gt;__replace_page() to unconditional decrease the\nRSS count and old_folio\u0026apos;s refcount.\n\nTherefore, two bugs are introduced:\n\n 1. The RSS count is incorrect, when process exit, the check_mm() report\n error \u0026quot;Bad rss-count\u0026quot;.\n\n 2. The reserved folio (zero folio) is freed when folio-\u0026gt;refcount is zero,\n then free_pages_prepare-\u0026gt;free_page_is_bad() report error\n \u0026quot;Bad page state\u0026quot;.\n\nThere is more, the following warning could also theoretically be triggered:\n\n __replace_page()\n -\u0026gt; ...\n -\u0026gt; folio_remove_rmap_pte()\n -\u0026gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)\n\nConsidering that uprobe hit on the zero folio is a very rare case, just\nreject zero old folio immediately after get_user_page_vma_remote().\n\n[ mingo: Cleaned up the changelog ](CVE-2025-21881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\novl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up\n\nThe issue was caused by dput(upper) being called before\novl_dentry_update_reval(), while upper-\u0026gt;d_flags was still\naccessed in ovl_dentry_remote().\n\nMove dput(upper) after its last use to prevent use-after-free.\n\nBUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\nBUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc3/0x620 mm/kasan/report.c:488\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\n ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n ovl_link_up fs/overlayfs/copy_up.c:610 [inline]\n ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170\n ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223\n ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136\n vfs_rename+0xf84/0x20a0 fs/namei.c:4893\n...\n \u0026lt;/TASK\u0026gt;(CVE-2025-21887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpio: aggregator: protect driver attr handlers against module unload\n\nBoth new_device_store and delete_device_store touch module global\nresources (e.g. gpio_aggregator_lock). To prevent race conditions with\nmodule unload, a reference needs to be held.\n\nAdd try_module_get() in these handlers.\n\nFor new_device_store, this eliminates what appears to be the most dangerous\nscenario: if an id is allocated from gpio_aggregator_idr but\nplatform_device_register has not yet been called or completed, a concurrent\nmodule unload could fail to unregister/delete the device, leaving behind a\ndangling platform device/GPIO forwarder. This can result in various issues.\nThe following simple reproducer demonstrates these problems:\n\n #!/bin/bash\n while :; do\n # note: whether \u0026apos;gpiochip0 0\u0026apos; exists or not does not matter.\n echo \u0026apos;gpiochip0 0\u0026apos; \u0026gt; /sys/bus/platform/drivers/gpio-aggregator/new_device\n done \u0026amp;\n while :; do\n modprobe gpio-aggregator\n modprobe -r gpio-aggregator\n done \u0026amp;\n wait\n\n Starting with the following warning, several kinds of warnings will appear\n and the system may become unstable:\n\n ------------[ cut here ]------------\n list_del corruption, ffff888103e2e980-\u0026gt;next is LIST_POISON1 (dead000000000100)\n WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120\n [...]\n RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __list_del_entry_valid_or_report+0xa3/0x120\n ? __warn.cold+0x93/0xf2\n ? __list_del_entry_valid_or_report+0xa3/0x120\n ? report_bug+0xe6/0x170\n ? __irq_work_queue_local+0x39/0xe0\n ? handle_bug+0x58/0x90\n ? exc_invalid_op+0x13/0x60\n ? asm_exc_invalid_op+0x16/0x20\n ? __list_del_entry_valid_or_report+0xa3/0x120\n gpiod_remove_lookup_table+0x22/0x60\n new_device_store+0x315/0x350 [gpio_aggregator]\n kernfs_fop_write_iter+0x137/0x1f0\n vfs_write+0x262/0x430\n ksys_write+0x60/0xd0\n do_syscall_64+0x6c/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [...]\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---(CVE-2025-21943)",
"id": "OESA-2025-1410",
"modified": "2026-08-06T11:08:30Z",
"published": "2025-04-11T11:08:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1410"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47660"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49443"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49513"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49553"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21718"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21816"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21943"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47660",
"CVE-2022-49443",
"CVE-2022-49513",
"CVE-2022-49553",
"CVE-2023-53001",
"CVE-2024-56642",
"CVE-2024-56664",
"CVE-2024-57951",
"CVE-2024-58055",
"CVE-2025-21715",
"CVE-2025-21718",
"CVE-2025-21722",
"CVE-2025-21726",
"CVE-2025-21727",
"CVE-2025-21785",
"CVE-2025-21791",
"CVE-2025-21804",
"CVE-2025-21816",
"CVE-2025-21823",
"CVE-2025-21863",
"CVE-2025-21881",
"CVE-2025-21887",
"CVE-2025-21943"
]
}
RHSA-2023:2458
Vulnerability from csaf_redhat - Published: 2023-05-09 10:04 - Updated: 2026-09-13 18:16A vulnerability was found in the Linux kernel's cpufreq subsystem. The `dbs_data` struct, which embeds a `kobject`, improperly attempts to free the struct using `kfree()` rather than through the proper `release()` method. This issue can lead to a use-after-free scenario, resulting in system instability, memory corruption, or potential arbitrary code execution.
RHSA-2023:2951
Vulnerability from csaf_opensuse - Published: 2023-05-16 00:00 - Updated: 2026-09-15 08:43Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.