In the Linux kernel, the following vulnerability has been resolved: skbuff: Fix a race between coalescing and releasing SKBs Commit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragment recycling") allowed coalescing to proceed with non page pool page and page pool page when @from is cloned, i.e. to->pp_recycle --> false from->pp_recycle --> true skb_cloned(from) --> true However, it actually requires skb_cloned(@from) to hold true until coalescing finishes in this situation. If the other cloned SKB is released while the merging is in process, from_shinfo->nr_frags will be set to 0 toward the end of the function, causing the increment of frag page _refcount to be unexpectedly skipped resulting in inconsistent reference counts. Later when SKB(@to) is released, it frees the page directly even though the page pool page is still in use, leading to use-after-free or double-free errors. So it should be prohibited. The double-free error message below prompted us to investigate: BUG: Bad page state in process swapper/1 pfn:0e0d1 page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000 index:0x2 pfn:0xe0d1 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000 raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000 page dumped because: nonzero _refcount CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+ Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_pcp_prepare+0x260/0x2f0 free_unref_page+0x20/0x1c0 skb_release_data+0x10b/0x1a0 napi_consume_skb+0x56/0x150 net_rx_action+0xf0/0x350 ? __napi_schedule+0x79/0x90 __do_softirq+0xc8/0x2b1 __irq_exit_rcu+0xb9/0xf0 common_interrupt+0x82/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 RIP: 0010:default_idle+0xb/0x20

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: skbuff: Fix a race between coalescing     and releasing SKBs Commit 1effe8ca4e34 (skbuff: fix coalescing for page_pool fragment recycling) allowed     coalescing to proceed with non page pool page and page pool page when @from is cloned, i.e. to->pp_recycle
    --> false from->pp_recycle --> true skb_cloned(from) --> true However, it actually requires     skb_cloned(@from) to hold true until coalescing finishes in this situation. If the other cloned SKB is     released while the merging is in process, from_shinfo->nr_frags will be set to 0 toward the end of the     function, causing the increment of frag page _refcount to be unexpectedly skipped resulting in     inconsistent reference counts. Later when SKB(@to) is released, it frees the page directly even though the     page pool page is still in use, leading to use-after-free or double-free errors. So it should be     prohibited. The double-free error message below prompted us to investigate: BUG: Bad page state in process     swapper/1 pfn:0e0d1 page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000 index:0x2     pfn:0xe0d1 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000     0000000000000000 ffffffff00000101 0000000000000000 raw: 0000000000000002 0000000000000000 ffffffffffffffff     0000000000000000 page dumped because: nonzero _refcount CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+     Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_pcp_prepare+0x260/0x2f0     free_unref_page+0x20/0x1c0 skb_release_data+0x10b/0x1a0 napi_consume_skb+0x56/0x150     net_rx_action+0xf0/0x350 ? __napi_schedule+0x79/0x90 __do_softirq+0xc8/0x2b1 __irq_exit_rcu+0xb9/0xf0     common_interrupt+0x82/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 RIP: 0010:default_idle+0xb/0x20     (CVE-2023-53186)

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

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2023-169 advisory.

    An out-of-bounds memory access flaw was found in the Linux kernel's XFS file system in how a user restores     an XFS image after failure (with a dirty log journal). This flaw allows a local user to crash or     potentially escalate their privileges on the system. (CVE-2023-2124)

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

    skbuff: Fix a race between coalescing and releasing SKBs (CVE-2023-53186)

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

    raw: Fix NULL deref in raw_get_next(). (CVE-2023-53198)

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

    nfsd: call op_release, even when op_func returns an error (CVE-2023-53241)

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

    Drivers: vmbus: Check for channel allocation before looking up relids (CVE-2023-53273)

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

    sctp: check send stream number after wait_for_sndbuf (CVE-2023-53296)

Tenable has extracted the preceding description block directly from the tested product 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 version of kernel installed on the remote host is prior to 5.15.108-65.141. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.15-2023-017 advisory.

    An out-of-bounds memory access flaw was found in the Linux kernel's XFS file system in how a user restores     an XFS image after failure (with a dirty log journal). This flaw allows a local user to crash or     potentially escalate their privileges on the system. (CVE-2023-2124)

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

    skbuff: Fix a race between coalescing and releasing SKBs (CVE-2023-53186)

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

    Drivers: vmbus: Check for channel allocation before looking up relids (CVE-2023-53273)

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

    sctp: check send stream number after wait_for_sndbuf (CVE-2023-53296)

Tenable has extracted the preceding description block directly from the tested product 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
264929	Linux Distros Unpatched Vulnerability : CVE-2023-53186	Nessus	Misc.	high
175085	Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2023-169)	Nessus	Amazon Linux Local Security Checks	high
174975	Amazon Linux 2 : kernel, --advisory ALAS2KERNEL-5.15-2023-017 (ALASKERNEL-5.15-2023-017)	Nessus	Amazon Linux Local Security Checks	high

Detections

Analytics

CVE-2023-53186

medium

Tenable Plugins

high

high

high