In the Linux kernel, the following vulnerability has been resolved: rose: Fix NULL pointer dereference in rose_send_frame() The syzkaller reported an issue: KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387] CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: rcu_gp srcu_invoke_callbacks RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101 Call Trace: <IRQ> rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255 rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009 rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111 call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790 __run_timers kernel/time/timer.c:1768 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803 __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571 [...] </IRQ> It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is called in the rose_send_frame(). It's the first occurrence of the `neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr. It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf ("rose: Fix Null pointer dereference in rose_send_frame()") ever. But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8 ("rose: check NULL rose_loopback_neigh->loopback") again. We fix it by add NULL check in rose_transmit_clear_request(). When the 'dev' in 'neigh' is NULL, we don't reply the request and just clear it. syzkaller don't provide repro, and I provide a syz repro like: r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2) ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201}) r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0) bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40) connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-988696 advisory.

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

    rose: Fix NULL pointer dereference in rose_send_frame()

    The syzkaller reported an issue:

    KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]     CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0     Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022     Workqueue: rcu_gp srcu_invoke_callbacks     RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101     Call Trace:
     <IRQ>      rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255      rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009      rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111      call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474      expire_timers kernel/time/timer.c:1519 [inline]
     __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
     __run_timers kernel/time/timer.c:1768 [inline]      run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
     __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571      [...]      </IRQ>

    It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is     called in the rose_send_frame(). It's the first occurrence of the     `neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and     the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr.

    It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf     (rose: Fix Null pointer dereference in rose_send_frame()) ever.
    But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8     (rose: check NULL rose_loopback_neigh->loopback) again.

    We fix it by add NULL check in rose_transmit_clear_request(). When     the 'dev' in 'neigh' is NULL, we don't reply the request and just     clear it.

    syzkaller don't provide repro, and I provide a syz repro like:
    r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)     ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201})     r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0)     bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default,     @null]}, 0x40)     connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc,     0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-990138 advisory.

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

    rose: Fix NULL pointer dereference in rose_send_frame()

    The syzkaller reported an issue:

    KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]     CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0     Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022     Workqueue: rcu_gp srcu_invoke_callbacks     RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101     Call Trace:
     <IRQ>      rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255      rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009      rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111      call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474      expire_timers kernel/time/timer.c:1519 [inline]
     __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
     __run_timers kernel/time/timer.c:1768 [inline]      run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
     __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571      [...]      </IRQ>

    It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is     called in the rose_send_frame(). It's the first occurrence of the     `neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and     the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr.

    It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf     (rose: Fix Null pointer dereference in rose_send_frame()) ever.
    But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8     (rose: check NULL rose_loopback_neigh->loopback) again.

    We fix it by add NULL check in rose_transmit_clear_request(). When     the 'dev' in 'neigh' is NULL, we don't reply the request and just     clear it.

    syzkaller don't provide repro, and I provide a syz repro like:
    r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)     ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201})     r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0)     bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default,     @null]}, 0x40)     connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc,     0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-986622 advisory.

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

    rose: Fix NULL pointer dereference in rose_send_frame()

    The syzkaller reported an issue:

    KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]     CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0     Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022     Workqueue: rcu_gp srcu_invoke_callbacks     RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101     Call Trace:
     <IRQ>      rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255      rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009      rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111      call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474      expire_timers kernel/time/timer.c:1519 [inline]
     __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
     __run_timers kernel/time/timer.c:1768 [inline]      run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
     __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571      [...]      </IRQ>

    It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is     called in the rose_send_frame(). It's the first occurrence of the     `neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and     the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr.

    It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf     (rose: Fix Null pointer dereference in rose_send_frame()) ever.
    But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8     (rose: check NULL rose_loopback_neigh->loopback) again.

    We fix it by add NULL check in rose_transmit_clear_request(). When     the 'dev' in 'neigh' is NULL, we don't reply the request and just     clear it.

    syzkaller don't provide repro, and I provide a syz repro like:
    r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)     ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201})     r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0)     bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default,     @null]}, 0x40)     connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc,     0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-986852 advisory.

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

    rose: Fix NULL pointer dereference in rose_send_frame()

    The syzkaller reported an issue:

    KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]     CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0     Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022     Workqueue: rcu_gp srcu_invoke_callbacks     RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101     Call Trace:
     <IRQ>      rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255      rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009      rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111      call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474      expire_timers kernel/time/timer.c:1519 [inline]
     __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
     __run_timers kernel/time/timer.c:1768 [inline]      run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
     __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571      [...]      </IRQ>

    It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is     called in the rose_send_frame(). It's the first occurrence of the     `neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and     the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr.

    It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf     (rose: Fix Null pointer dereference in rose_send_frame()) ever.
    But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8     (rose: check NULL rose_loopback_neigh->loopback) again.

    We fix it by add NULL check in rose_transmit_clear_request(). When     the 'dev' in 'neigh' is NULL, we don't reply the request and just     clear it.

    syzkaller don't provide repro, and I provide a syz repro like:
    r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)     ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201})     r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0)     bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default,     @null]}, 0x40)     connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc,     0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In the Linux kernel, the following vulnerability has been resolved: rose: Fix NULL pointer dereference in     rose_send_frame() The syzkaller reported an issue: KASAN: null-ptr-deref in range     [0x0000000000000380-0x0000000000000387] CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted     6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine,     BIOS Google 09/22/2022 Workqueue: rcu_gp srcu_invoke_callbacks RIP: 0010:rose_send_frame+0x1dd/0x2f0     net/rose/rose_link.c:101 Call Trace: <IRQ> rose_transmit_clear_request+0x1d5/0x290     net/rose/rose_link.c:255 rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009     rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111 call_timer_fn+0x1a0/0x6b0     kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers.part.0+0x674/0xa80     kernel/time/timer.c:1790 __run_timers kernel/time/timer.c:1768 [inline] run_timer_softirq+0xb3/0x1d0     kernel/time/timer.c:1803 __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571 [...] </IRQ> It triggers NULL     pointer dereference when 'neigh->dev->dev_addr' is called in the rose_send_frame(). It's the first     occurrence of the `neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and the 'dev' in     'rose_loopback_neigh' is initialized sa nullptr. It had been fixed by commit     3b3fd068c56e3fbea30090859216a368398e39bf (rose: Fix Null pointer dereference in rose_send_frame()) ever.
    But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8 (rose: check NULL     rose_loopback_neigh->loopback) again. We fix it by add NULL check in rose_transmit_clear_request(). When     the 'dev' in 'neigh' is NULL, we don't reply the request and just clear it. syzkaller don't provide repro,     and I provide a syz repro like: r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)     ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201}) r1 =     syz_init_net_socket$rose(0xb, 0x5, 0x0) bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0,     [@null, @null, @netrom, @netrom, @default, @null]}, 0x40) connect$rose(r1, &(0x7f0000000240)=@short={0xb,     @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb,     0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c) (CVE-2022-49916)

Note that Nessus relies on the presence of the package as reported by the vendor.

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:02262-1 advisory.

    The SUSE Linux Enterprise 15 SP4 kernel was updated to receive various security bugfixes.

    The following security bugs were fixed:

    - CVE-2022-49110: netfilter: conntrack: revisit gc autotuning (bsc#1237981).
    - CVE-2022-49139: Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt (bsc#1238032).
    - CVE-2022-49767: 9p/trans_fd: always use O_NONBLOCK read/write (bsc#1242493).
    - CVE-2022-49775: tcp: cdg: allow tcp_cdg_release() to be called multiple times (bsc#1242245).
    - CVE-2022-49858: octeontx2-pf: Fix SQE threshold checking (bsc#1242589).
    - CVE-2023-53058: net/mlx5: E-Switch, Fix an Oops in error handling code (bsc#1242237).
    - CVE-2023-53060: igb: revert rtnl_lock() that causes deadlock (bsc#1242241).
    - CVE-2023-53064: iavf: Fix hang on reboot with ice (bsc#1242222).
    - CVE-2023-53066: qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info (bsc#1242227).
    - CVE-2023-53079: net/mlx5: Fix steering rules cleanup (bsc#1242765).
    - CVE-2023-53114: i40e: Fix kernel crash during reboot when adapter is in recovery mode (bsc#1242398).
    - CVE-2023-53134: bnxt_en: Avoid order-5 memory allocation for TPA data (bsc#1242380)
    - CVE-2024-53168: net: make sock_inuse_add() available (bsc#1234887).
    - CVE-2024-56558: nfsd: make sure exp active before svc_export_show (bsc#1235100).
    - CVE-2025-21888: RDMA/mlx5: Fix a WARN during dereg_mr for DM type (bsc#1240177).
    - CVE-2025-21999: proc: fix UAF in proc_get_inode() (bsc#1240802).
    - CVE-2025-22056: netfilter: nft_tunnel: fix geneve_opt type confusion addition (bsc#1241525).
    - CVE-2025-22060: net: mvpp2: Prevent parser TCAM memory corruption (bsc#1241526).
    - CVE-2025-23138: watch_queue: fix pipe accounting mismatch (bsc#1241648).
    - CVE-2025-23145: mptcp: fix NULL pointer in can_accept_new_subflow (bsc#1242596).
    - CVE-2025-37785: ext4: fix OOB read when checking dotdot dir (bsc#1241640).
    - CVE-2025-37789: net: openvswitch: fix nested key length validation in the set() action (bsc#1242762).


Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:02173-1 advisory.

    The SUSE Linux Enterprise 15 SP5 kernel was updated to receive various security bugfixes.


    The following security bugs were fixed:

    - CVE-2022-49775: tcp: cdg: allow tcp_cdg_release() to be called multiple times (bsc#1242245).
    - CVE-2024-53168: net: make sock_inuse_add() available (bsc#1234887).
    - CVE-2024-56558: nfsd: make sure exp active before svc_export_show (bsc#1235100).
    - CVE-2025-21999: proc: fix UAF in proc_get_inode() (bsc#1240802).
    - CVE-2025-22056: netfilter: nft_tunnel: fix geneve_opt type confusion addition (bsc#1241525).
    - CVE-2025-23145: mptcp: fix NULL pointer in can_accept_new_subflow (bsc#1242596).
    - CVE-2025-37789: net: openvswitch: fix nested key length validation in the set() action (bsc#1242762).
    - CVE-2024-28956: x86/its: Add support for ITS-safe indirect thunk (bsc#1242006).
    - CVE-2025-37785: ext4: fix OOB read when checking dotdot dir (bsc#1241640).


Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
273656	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-988696)	Nessus	Unity Linux Local Security Checks	medium
272397	Unity Linux 20.1050e Security Update: kernel (UTSA-2025-990138)	Nessus	Unity Linux Local Security Checks	medium
268766	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-986622)	Nessus	Unity Linux Local Security Checks	medium
268319	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-986852)	Nessus	Unity Linux Local Security Checks	medium
266037	Linux Distros Unpatched Vulnerability : CVE-2022-49916	Nessus	Misc.	medium
241966	SUSE SLES15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2025:02262-1)	Nessus	SuSE Local Security Checks	high
241036	SUSE SLES15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2025:02173-1)	Nessus	SuSE Local Security Checks	medium

Detections

Analytics

CVE-2022-49916

medium

Tenable Plugins

medium

medium

medium

medium

medium

high

medium