In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-529.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: ipvs: properly dereference pe in     ip_vs_add_service Use pe directly to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27:
    warning: dereference of noderef expression (CVE-2024-42322)

  - In the Linux kernel, the following vulnerability has been resolved: fscache: delete     fscache_cookie_lru_timer when fscache exits to avoid UAF The fscache_cookie_lru_timer is initialized when     the fscache module is inserted, but is not deleted when the fscache module is removed. If timer_reduce()     is called before removing the fscache module, the fscache_cookie_lru_timer will be added to the timer list     of the current cpu. Afterwards, a use-after-free will be triggered in the softIRQ after removing the     fscache module, as follows: ================================================================== BUG: unable     to handle page fault for address: fffffbfff803c9e9 PF: supervisor read access in kernel mode PF:
    error_code(0x0000) - not-present page PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0 Oops:
    Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855     Tainted: [W]=WARN RIP: 0010:__run_timer_base.part.0+0x254/0x8a0 Call Trace: <IRQ>     tmigr_handle_remote_up+0x627/0x810 __walk_groups.isra.0+0x47/0x140 tmigr_handle_remote+0x1fa/0x2f0     handle_softirqs+0x180/0x590 irq_exit_rcu+0x84/0xb0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ> <TASK>     asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 default_idle_call+0x38/0x60     do_idle+0x2b5/0x300 cpu_startup_entry+0x54/0x60 start_secondary+0x20d/0x280 common_startup_64+0x13e/0x148     </TASK> Modules linked in: [last unloaded: netfs]     ================================================================== Therefore delete     fscache_cookie_lru_timer when removing the fscahe module. (CVE-2024-46786)

  - In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent     async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients     can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for     a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the     number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements     a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY.
    The requesting client can choose to send the request again after a delay or fall back to a traditional     read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in     future patches. (CVE-2024-49974)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid     NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11     at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module     registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to     restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points     out that this is a general issue, direct users of the set/getsockopt interface can call into     targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for     similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this     is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. -     targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile     with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most     matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by     ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail     out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in     iptables.git. (CVE-2024-50038)

  - In the Linux kernel, the following vulnerability has been resolved: platform/x86/intel/pmc: Fix     pmc_core_iounmap to call iounmap for valid addresses Commit 50c6dbdfd16e (x86/ioremap: Improve iounmap()     address range checks) introduces a WARN when adrress ranges of iounmap are invalid. On Thinkpad P1 Gen 7     (Meteor Lake-P) this caused the following warning to appear: WARNING: CPU: 7 PID: 713 at     arch/x86/mm/ioremap.c:461 iounmap+0x58/0x1f0 Modules linked in: rfkill(+) snd_timer(+) fjes(+) snd     soundcore intel_pmc_core(+) int3403_thermal(+) int340x_thermal_zone intel_vsec pmt_telemetry acpi_pad     pmt_class acpi_tad int3400_thermal acpi_thermal_rel joydev loop nfnetlink zram xe drm_suballoc_helper     nouveau i915 mxm_wmi drm_ttm_helper gpu_sched drm_gpuvm drm_exec drm_buddy i2c_algo_bit crct10dif_pclmul     crc32_pclmul ttm crc32c_intel polyval_clmulni rtsx_pci_sdmmc ucsi_acpi polyval_generic mmc_core     hid_multitouch drm_display_helper ghash_clmulni_intel typec_ucsi nvme sha512_ssse3 video sha256_ssse3     nvme_core intel_vpu sha1_ssse3 rtsx_pci cec typec nvme_auth i2c_hid_acpi i2c_hid wmi pinctrl_meteorlake     serio_raw ip6_tables ip_tables fuse CPU: 7 UID: 0 PID: 713 Comm: (udev-worker) Not tainted     6.12.0-rc2iounmap+ #42 Hardware name: LENOVO 21KWCTO1WW/21KWCTO1WW, BIOS N48ET19W (1.06 ) 07/18/2024 RIP:
    0010:iounmap+0x58/0x1f0 Code: 85 6a 01 00 00 48 8b 05 e6 e2 28 04 48 39 c5 72 19 eb 26 cc cc cc 48 ba 00     00 00 00 00 00 32 00 48 8d 44 02 ff 48 39 c5 72 23 <0f> 0b 48 83 c4 08 5b 5d 41 5c c3 cc cc cc cc 48 ba 00     00 00 00 00 RSP: 0018:ffff888131eff038 EFLAGS: 00010207 RAX: ffffc90000000000 RBX: 0000000000000000 RCX:
    ffff888e33b80000 RDX: dffffc0000000000 RSI: ffff888e33bc29c0 RDI: 0000000000000000 RBP: 0000000000000000     R08: ffff8881598a8000 R09: ffff888e2ccedc10 R10: 0000000000000003 R11: ffffffffb3367634 R12:
    00000000fe000000 R13: ffff888101d0da28 R14: ffffffffc2e437e0 R15: ffff888110b03b28 FS:
    00007f3c1d4b3980(0000) GS:ffff888e33b80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00005651cfc93578 CR3: 0000000124e4c002 CR4: 0000000000f70ef0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7:
    0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn.cold+0xb6/0x176 ? iounmap+0x58/0x1f0 ?     report_bug+0x1f4/0x2b0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ?     iounmap+0x58/0x1f0 pmc_core_ssram_get_pmc+0x477/0x6c0 [intel_pmc_core] ?
    __pfx_pmc_core_ssram_get_pmc+0x10/0x10 [intel_pmc_core] ? __pfx_do_pci_enable_device+0x10/0x10 ?     pci_wait_for_pending+0x60/0x110 ? pci_enable_device_flags+0x1e3/0x2e0 ? __pfx_mtl_core_init+0x10/0x10     [intel_pmc_core] pmc_core_ssram_init+0x7f/0x110 [intel_pmc_core] mtl_core_init+0xda/0x130 [intel_pmc_core]     ? __mutex_init+0xb9/0x130 pmc_core_probe+0x27e/0x10b0 [intel_pmc_core] ? _raw_spin_lock_irqsave+0x96/0xf0     ? __pfx_pmc_core_probe+0x10/0x10 [intel_pmc_core] ? __pfx_mutex_unlock+0x10/0x10 ?
    __pfx_mutex_lock+0x10/0x10 ? device_pm_check_callbacks+0x82/0x370 ? acpi_dev_pm_attach+0x234/0x2b0     platform_probe+0x9f/0x150 really_probe+0x1e0/0x8a0 __driver_probe_device+0x18c/0x370 ?
    __pfx___driver_attach+0x10/0x10 driver_probe_device+0x4a/0x120 __driver_attach+0x190/0x4a0 ?
    __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x103/0x180 ? __pfx_bus_for_each_dev+0x10/0x10 ?     klist_add_tail+0x136/0x270 bus_add_driver+0x2fc/0x540 driver_register+0x1a5/0x360 ?
    __pfx_pmc_core_driver_init+0x10/0x10 [intel_pmc_core] do_one_initcall+0xa4/0x380 ?
    __pfx_do_one_initcall+0x10/0x10 ? kasan_unpoison+0x44/0x70 do_init_module+0x296/0x800     load_module+0x5090/0x6ce0 ? __pfx_load_module+0x10/0x10 ? ima_post_read_file+0x193/0x200 ?
    __pfx_ima_post_read_file+0x10/0x10 ? rw_verify_area+0x152/0x4c0 ? kernel_read_file+0x257/0x750 ?
    __pfx_kernel_read_file+0x10/0x10 ? __pfx_filemap_get_read_batch+0x10/0x10 ?     init_module_from_file+0xd1/0x130 init_module_from_file+0xd1/0x130 ? __pfx_init_module_from_file+0x10/0
    ---truncated--- (CVE-2024-50107)

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

An update of the linux package has been released.

ID	Name	Product	Family	Severity
211516	CentOS 9 : kernel-5.14.0-529.el9	Nessus	CentOS Local Security Checks	high
210758	Photon OS 5.0: Linux PHSA-2024-5.0-0393	Nessus	PhotonOS Local Security Checks	high

Detections

Analytics

CVE-2024-50038

medium

Tenable Plugins

high

high