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

  - In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_netdev_start(): fix     UAF for rx_kref of j1939_priv It will trigger UAF for rx_kref of j1939_priv as following. cpu0 cpu1     j1939_sk_bind(socket0, ndev0, ...) j1939_netdev_start j1939_sk_bind(socket1, ndev0, ...)     j1939_netdev_start j1939_priv_set j1939_priv_get_by_ndev_locked j1939_jsk_add ..... j1939_netdev_stop     kref_put_lock(&priv->rx_kref, ...) kref_get(&priv->rx_kref, ...) REFCOUNT_WARN(addition on 0;...)     ==================================================== refcount_t: addition on 0; use-after-free. WARNING:
    CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0 RIP:
    0010:refcount_warn_saturate+0x169/0x1e0 Call Trace: j1939_netdev_start+0x68b/0x920     j1939_sk_bind+0x426/0xeb0 ? security_socket_bind+0x83/0xb0 The rx_kref's kref_get() and kref_put() should     use j1939_netdev_lock to protect. (CVE-2021-47459)

  - In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix mirred deadlock on     device recursion When the mirred action is used on a classful egress qdisc and a packet is mirrored or     redirected to self we hit a qdisc lock deadlock. See trace below. [..... other info removed for     brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING:
    possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [     82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [     82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [     82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
    __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [     82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906]     lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [     82.890906] [..... other info removed for brevity....] Example setup (eth0->eth0) to recreate tc qdisc add     dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \     action mirred egress redirect dev eth0 Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0     root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred     egress redirect dev eth1 tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle     1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 We fix this by adding an owner     field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time,     if the qdisc owner is the same CPU, the packet is dropped to break the loop. (CVE-2024-27010)

  - In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds     in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B     sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode
    - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. -     side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf     Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing     gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the     constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and     gsm->mru. All other checks remain as we still need to limit the data according to the user configuration     and actual payload size. (CVE-2024-36016)

  - In the Linux kernel, the following vulnerability has been resolved: rtnetlink: Correct nested     IFLA_VF_VLAN_LIST attribute validation Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a     struct ifla_vf_vlan_info so the size of such attribute needs to be at least of sizeof(struct     ifla_vf_vlan_info) which is 14 bytes. The current size validation in do_setvfinfo is against NLA_HDRLEN (4     bytes) which is less than sizeof(struct ifla_vf_vlan_info) so this validation is not enough and a too     small attribute might be cast to a struct ifla_vf_vlan_info, this might result in an out of bands read     access when accessing the saved (casted) entry in ivvl. (CVE-2024-36017)

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

Detections

Analytics

CentOS 9 : kernel-5.14.0-479.el9

high Nessus Plugin ID 202393

Version 1.2

Version 1.1

Version 1.2 Jan 15, 2025, 7:16 AM CVSS metrics ("CVSSv2 score" set to 6.8) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C") CVSS metrics ("CVSSv3 score" set to 7.8) CVSS metrics ("CVSSv3 vector" set to "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H") CVSSv2 score source (changed from "CVE-2024-36016" to "CVE-2021-47459") Plugin Feed: 202501150716
Version 1.1 Jul 15, 2024, 10:15 PM New Plugin Feed: 202407152215