Homepage

NULL Pointer Dereference Affecting kernel-zfcpdump package, versions <0:4.18.0-553.5.1.el8_10

Severity

 Recommended
0.0
medium
0
10

Based on AlmaLinux security rating.

Threat Intelligence

EPSS
0.04% (5th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-ALMALINUX8-KERNELZFCPDUMP-7214630
  • published5 Jun 2024
  • disclosed5 Jun 2024
Report a new vulnerability Found a mistake?

Introduced: 5 Jun 2024

CVE-2024-26615  (opens in a new tab)
CWE-476  (opens in a new tab)

How to fix?

Upgrade AlmaLinux:8 kernel-zfcpdump to version 0:4.18.0-553.5.1.el8_10 or higher.
This issue was patched in ALSA-2024:3618.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump package and not the kernel-zfcpdump package as distributed by AlmaLinux. See How to fix? for AlmaLinux:8 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix illegal rmb_desc access in SMC-D connection dump

A crash was found when dumping SMC-D connections. It can be reproduced by following steps:

  • run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>

  • continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D'

BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76

It is possible that the connection is in process of being established when we dump it. Assumed that the connection has been registered in a link group by smc_conn_create() but the rmb_desc has not yet been initialized by smc_buf_create(), thus causing the illegal access to conn->rmb_desc. So fix it by checking before dump.

References

CVSS Scores

version 3.1