gsd-2021-47185
Vulnerability from gsd
Modified
2024-04-03 05:03
Details
In the Linux kernel, the following vulnerability has been resolved:
tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,
which look like this one:
Workqueue: events_unbound flush_to_ldisc
Call trace:
dump_backtrace+0x0/0x1ec
show_stack+0x24/0x30
dump_stack+0xd0/0x128
panic+0x15c/0x374
watchdog_timer_fn+0x2b8/0x304
__run_hrtimer+0x88/0x2c0
__hrtimer_run_queues+0xa4/0x120
hrtimer_interrupt+0xfc/0x270
arch_timer_handler_phys+0x40/0x50
handle_percpu_devid_irq+0x94/0x220
__handle_domain_irq+0x88/0xf0
gic_handle_irq+0x84/0xfc
el1_irq+0xc8/0x180
slip_unesc+0x80/0x214 [slip]
tty_ldisc_receive_buf+0x64/0x80
tty_port_default_receive_buf+0x50/0x90
flush_to_ldisc+0xbc/0x110
process_one_work+0x1d4/0x4b0
worker_thread+0x180/0x430
kthread+0x11c/0x120
In the testcase pty04, The first process call the write syscall to send
data to the pty master. At the same time, the workqueue will do the
flush_to_ldisc to pop data in a loop until there is no more data left.
When the sender and workqueue running in different core, the sender sends
data fastly in full time which will result in workqueue doing work in loop
for a long time and occuring softlockup in flush_to_ldisc with kernel
configured without preempt. So I add need_resched check and cond_resched
in the flush_to_ldisc loop to avoid it.
Aliases
{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2021-47185"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: tty_buffer: Fix the softlockup issue in flush_to_ldisc\n\nWhen running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,\nwhich look like this one:\n\n Workqueue: events_unbound flush_to_ldisc\n Call trace:\n dump_backtrace+0x0/0x1ec\n show_stack+0x24/0x30\n dump_stack+0xd0/0x128\n panic+0x15c/0x374\n watchdog_timer_fn+0x2b8/0x304\n __run_hrtimer+0x88/0x2c0\n __hrtimer_run_queues+0xa4/0x120\n hrtimer_interrupt+0xfc/0x270\n arch_timer_handler_phys+0x40/0x50\n handle_percpu_devid_irq+0x94/0x220\n __handle_domain_irq+0x88/0xf0\n gic_handle_irq+0x84/0xfc\n el1_irq+0xc8/0x180\n slip_unesc+0x80/0x214 [slip]\n tty_ldisc_receive_buf+0x64/0x80\n tty_port_default_receive_buf+0x50/0x90\n flush_to_ldisc+0xbc/0x110\n process_one_work+0x1d4/0x4b0\n worker_thread+0x180/0x430\n kthread+0x11c/0x120\n\nIn the testcase pty04, The first process call the write syscall to send\ndata to the pty master. At the same time, the workqueue will do the\nflush_to_ldisc to pop data in a loop until there is no more data left.\nWhen the sender and workqueue running in different core, the sender sends\ndata fastly in full time which will result in workqueue doing work in loop\nfor a long time and occuring softlockup in flush_to_ldisc with kernel\nconfigured without preempt. So I add need_resched check and cond_resched\nin the flush_to_ldisc loop to avoid it.",
"id": "GSD-2021-47185",
"modified": "2024-04-03T05:03:54.923722Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@kernel.org",
"ID": "CVE-2021-47185",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Linux",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "1da177e4c3f4",
"version_value": "0380f643f3a7"
},
{
"version_value": "not down converted",
"x_cve_json_5_version_data": {
"defaultStatus": "affected",
"versions": [
{
"lessThanOrEqual": "4.4.*",
"status": "unaffected",
"version": "4.4.293",
"versionType": "custom"
},
{
"lessThanOrEqual": "4.9.*",
"status": "unaffected",
"version": "4.9.291",
"versionType": "custom"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.256",
"versionType": "custom"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.218",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.162",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.82",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.5",
"versionType": "custom"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.16",
"versionType": "original_commit_for_fix"
}
]
}
}
]
}
}
]
},
"vendor_name": "Linux"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: tty_buffer: Fix the softlockup issue in flush_to_ldisc\n\nWhen running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,\nwhich look like this one:\n\n Workqueue: events_unbound flush_to_ldisc\n Call trace:\n dump_backtrace+0x0/0x1ec\n show_stack+0x24/0x30\n dump_stack+0xd0/0x128\n panic+0x15c/0x374\n watchdog_timer_fn+0x2b8/0x304\n __run_hrtimer+0x88/0x2c0\n __hrtimer_run_queues+0xa4/0x120\n hrtimer_interrupt+0xfc/0x270\n arch_timer_handler_phys+0x40/0x50\n handle_percpu_devid_irq+0x94/0x220\n __handle_domain_irq+0x88/0xf0\n gic_handle_irq+0x84/0xfc\n el1_irq+0xc8/0x180\n slip_unesc+0x80/0x214 [slip]\n tty_ldisc_receive_buf+0x64/0x80\n tty_port_default_receive_buf+0x50/0x90\n flush_to_ldisc+0xbc/0x110\n process_one_work+0x1d4/0x4b0\n worker_thread+0x180/0x430\n kthread+0x11c/0x120\n\nIn the testcase pty04, The first process call the write syscall to send\ndata to the pty master. At the same time, the workqueue will do the\nflush_to_ldisc to pop data in a loop until there is no more data left.\nWhen the sender and workqueue running in different core, the sender sends\ndata fastly in full time which will result in workqueue doing work in loop\nfor a long time and occuring softlockup in flush_to_ldisc with kernel\nconfigured without preempt. So I add need_resched check and cond_resched\nin the flush_to_ldisc loop to avoid it."
}
]
},
"generator": {
"engine": "bippy-d175d3acf727"
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://git.kernel.org/stable/c/0380f643f3a7a61b0845cdc738959c2ad5735d61",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/0380f643f3a7a61b0845cdc738959c2ad5735d61"
},
{
"name": "https://git.kernel.org/stable/c/b1ffc16ec05ae40d82b6e373322d62e9d6b54fbc",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/b1ffc16ec05ae40d82b6e373322d62e9d6b54fbc"
},
{
"name": "https://git.kernel.org/stable/c/4c1623651a0936ee197859824cdae6ebbd04d3ed",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/4c1623651a0936ee197859824cdae6ebbd04d3ed"
},
{
"name": "https://git.kernel.org/stable/c/4f300f47dbcf9c3d4b2ea76c8554c8f360400725",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/4f300f47dbcf9c3d4b2ea76c8554c8f360400725"
},
{
"name": "https://git.kernel.org/stable/c/d491c84df5c469dd9621863b6a770b3428137063",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/d491c84df5c469dd9621863b6a770b3428137063"
},
{
"name": "https://git.kernel.org/stable/c/77e9fed33056f2a88eba9dd4d2d5412f0c7d1f41",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/77e9fed33056f2a88eba9dd4d2d5412f0c7d1f41"
},
{
"name": "https://git.kernel.org/stable/c/5c34486f04700f1ba04907231dce0cc2705c2d7d",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/5c34486f04700f1ba04907231dce0cc2705c2d7d"
},
{
"name": "https://git.kernel.org/stable/c/3968ddcf05fb4b9409cd1859feb06a5b0550a1c1",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/3968ddcf05fb4b9409cd1859feb06a5b0550a1c1"
}
]
}
},
"nvd.nist.gov": {
"cve": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: tty_buffer: Fix the softlockup issue in flush_to_ldisc\n\nWhen running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,\nwhich look like this one:\n\n Workqueue: events_unbound flush_to_ldisc\n Call trace:\n dump_backtrace+0x0/0x1ec\n show_stack+0x24/0x30\n dump_stack+0xd0/0x128\n panic+0x15c/0x374\n watchdog_timer_fn+0x2b8/0x304\n __run_hrtimer+0x88/0x2c0\n __hrtimer_run_queues+0xa4/0x120\n hrtimer_interrupt+0xfc/0x270\n arch_timer_handler_phys+0x40/0x50\n handle_percpu_devid_irq+0x94/0x220\n __handle_domain_irq+0x88/0xf0\n gic_handle_irq+0x84/0xfc\n el1_irq+0xc8/0x180\n slip_unesc+0x80/0x214 [slip]\n tty_ldisc_receive_buf+0x64/0x80\n tty_port_default_receive_buf+0x50/0x90\n flush_to_ldisc+0xbc/0x110\n process_one_work+0x1d4/0x4b0\n worker_thread+0x180/0x430\n kthread+0x11c/0x120\n\nIn the testcase pty04, The first process call the write syscall to send\ndata to the pty master. At the same time, the workqueue will do the\nflush_to_ldisc to pop data in a loop until there is no more data left.\nWhen the sender and workqueue running in different core, the sender sends\ndata fastly in full time which will result in workqueue doing work in loop\nfor a long time and occuring softlockup in flush_to_ldisc with kernel\nconfigured without preempt. So I add need_resched check and cond_resched\nin the flush_to_ldisc loop to avoid it."
}
],
"id": "CVE-2021-47185",
"lastModified": "2024-04-10T19:49:51.183",
"metrics": {},
"published": "2024-04-10T19:15:47.383",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0380f643f3a7a61b0845cdc738959c2ad5735d61"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3968ddcf05fb4b9409cd1859feb06a5b0550a1c1"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4c1623651a0936ee197859824cdae6ebbd04d3ed"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4f300f47dbcf9c3d4b2ea76c8554c8f360400725"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5c34486f04700f1ba04907231dce0cc2705c2d7d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/77e9fed33056f2a88eba9dd4d2d5412f0c7d1f41"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b1ffc16ec05ae40d82b6e373322d62e9d6b54fbc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d491c84df5c469dd9621863b6a770b3428137063"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
}
}
}
Loading...
Loading...
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.