CVE-2022-49838

In the Linux kernel, the following vulnerability has been resolved: sctp: clear out_curr if all frag chunks of current msg are pruned A crash was reported by Zhen Chen: list_del corruption, ffffa035ddf01c18->next is NULL WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Call Trace: sctp_sched_dequeue_common+0x17/0x70 [sctp] sctp_sched_fcfs_dequeue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp] sctp_side_effects+0x37/0xe0 [sctp] sctp_do_sm+0xd0/0x230 [sctp] sctp_primitive_SEND+0x2f/0x40 [sctp] sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp] sctp_sendmsg+0x3d5/0x440 [sctp] sock_sendmsg+0x5b/0x70 and in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream out_curr outq while this outq was empty. Normally stream->out_curr must be set to NULL once all frag chunks of current msg are dequeued, as we can see in sctp_sched_dequeue_done(). However, in sctp_prsctp_prune_unsent() as it is not a proper dequeue, sctp_sched_dequeue_done() is not called to do this. This patch is to fix it by simply setting out_curr to NULL when the last frag chunk of current msg is dequeued from out_curr stream in sctp_prsctp_prune_unsent().
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc4:*:*:*:*:*:*

History

10 Nov 2025, 21:13

Type Values Removed Values Added
References () https://git.kernel.org/stable/c/2ea600b598dd3e061854dd4dd5b4c815397dfcea - () https://git.kernel.org/stable/c/2ea600b598dd3e061854dd4dd5b4c815397dfcea - Patch
References () https://git.kernel.org/stable/c/2f201ae14ae0f91dbf1cffea7bb1e29e81d4d108 - () https://git.kernel.org/stable/c/2f201ae14ae0f91dbf1cffea7bb1e29e81d4d108 - Patch
References () https://git.kernel.org/stable/c/3eff34e01062ec08fbb45ce2baaaa644550be821 - () https://git.kernel.org/stable/c/3eff34e01062ec08fbb45ce2baaaa644550be821 - Patch
References () https://git.kernel.org/stable/c/e27458b18b35caee4b27b37a4a9c503b93cae5cc - () https://git.kernel.org/stable/c/e27458b18b35caee4b27b37a4a9c503b93cae5cc - Patch
First Time Linux
Linux linux Kernel
CPE cpe:2.3:o:linux:linux_kernel:6.1:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1:rc3:*:*:*:*:*:*
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 5.5
CWE NVD-CWE-noinfo

02 May 2025, 13:53

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: borrar out_curr si se eliminan todos los fragmentos del mensaje actual. Zhen Chen informó de un fallo: corrupción de list_del, ffffa035ddf01c18->next es NULL ADVERTENCIA: CPU: 1 PID: 250682 en lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Rastreo de llamadas: sctp_sched_dequeue_common+0x17/0x70 [sctp] sctp_sched_fcfs_dequeue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp] sctp_side_effects+0x37/0xe0 [sctp] sctp_do_sm+0xd0/0x230 [sctp] sctp_primitive_SEND+0x2f/0x40 [sctp] sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp] sctp_sendmsg+0x3d5/0x440 [sctp] sock_sendmsg+0x5b/0x70 y en sctp_sched_fcfs_dequeue() quitó de la cola un fragmento del flujo out_curr outq mientras este outq estaba vacío. Normalmente, stream->out_curr debe establecerse en NULL una vez que se hayan desencolado todos los fragmentos del mensaje actual, como se puede ver en sctp_sched_dequeue_done(). Sin embargo, en sctp_prsctp_prune_unsent(), dado que no es una desencola adecuada, no se llama a sctp_sched_dequeue_done() para realizar esto. Este parche soluciona este problema simplemente estableciendo out_curr en NULL cuando se desencola el último fragmento del mensaje actual del flujo out_curr en sctp_prsctp_prune_unsent().

01 May 2025, 15:16

Type Values Removed Values Added
New CVE

Information

Published : 2025-05-01 15:16

Updated : 2025-11-10 21:13


NVD link : CVE-2022-49838

Mitre link : CVE-2022-49838

CVE.ORG link : CVE-2022-49838


JSON object : View

Products Affected

linux

  • linux_kernel