Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: Fix NULL pointer dereference in ethtool loopback test<br /> <br /> The ixgbe driver currently generates a NULL pointer dereference when<br /> performing the ethtool loopback test. This is due to the fact that there<br /> isn&amp;#39;t a q_vector associated with the test ring when it is setup as<br /> interrupts are not normally added to the test rings.<br /> <br /> To address this I have added code that will check for a q_vector before<br /> returning a napi_id value. If a q_vector is not present it will return a<br /> value of 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: fix wq cleanup of WQCFG registers<br /> <br /> A pre-release silicon erratum workaround where wq reset does not clear<br /> WQCFG registers was leaked into upstream code. Use wq reset command<br /> instead of blasting the MMIO region. This also address an issue where<br /> we clobber registers in future devices.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: clear MSIX permission entry on shutdown<br /> <br /> Add disabling/clearing of MSIX permission entries on device shutdown to<br /> mirror the enabling of the MSIX entries on probe. Current code left the<br /> MSIX enabled and the pasid entries still programmed at device shutdown.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: fix wq size store permission state<br /> <br /> WQ size can only be changed when the device is disabled. Current code<br /> allows change when device is enabled but wq is disabled. Change the check<br /> to detect device state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix clobbering of SWERR overflow bit on writeback<br /> <br /> Current code blindly writes over the SWERR and the OVERFLOW bits. Write<br /> back the bits actually read instead so the driver avoids clobbering the<br /> OVERFLOW bit that comes after the register is read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: footbridge: fix PCI interrupt mapping<br /> <br /> Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in<br /> pci_device_probe()"), the PCI code will call the IRQ mapping function<br /> whenever a PCI driver is probed. If these are marked as __init, this<br /> causes an oops if a PCI driver is loaded or bound after the kernel has<br /> initialised.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9063/1: mm: reduce maximum number of CPUs if DEBUG_KMAP_LOCAL is enabled<br /> <br /> The debugging code for kmap_local() doubles the number of per-CPU fixmap<br /> slots allocated for kmap_local(), in order to use half of them as guard<br /> regions. This causes the fixmap region to grow downwards beyond the start<br /> of its reserved window if the supported number of CPUs is large, and collide<br /> with the newly added virtual DT mapping right below it, which is obviously<br /> not good.<br /> <br /> One manifestation of this is EFI boot on a kernel built with NR_CPUS=32<br /> and CONFIG_DEBUG_KMAP_LOCAL=y, which may pass the FDT in highmem, resulting<br /> in block entries below the fixmap region that the fixmap code misidentifies<br /> as fixmap table entries, and subsequently tries to dereference using a<br /> phys-to-virt translation that is only valid for lowmem. This results in a<br /> cryptic splat such as the one below.<br /> <br /> ftrace: allocating 45548 entries in 89 pages<br /> 8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ch_ktls: Fix kernel panic<br /> <br /> Taking page refcount is not ideal and causes kernel panic<br /> sometimes. It&amp;#39;s better to take tx_ctx lock for the complete<br /> skb transmit, to avoid page cleanup if ACK received in middle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Make tcp_allowed_congestion_control readonly in non-init netns<br /> <br /> Currently, tcp_allowed_congestion_control is global and writable;<br /> writing to it in any net namespace will leak into all other net<br /> namespaces.<br /> <br /> tcp_available_congestion_control and tcp_allowed_congestion_control are<br /> the only sysctls in ipv4_net_table (the per-netns sysctl table) with a<br /> NULL data pointer; their handlers (proc_tcp_available_congestion_control<br /> and proc_allowed_congestion_control) have no other way of referencing a<br /> struct net. Thus, they operate globally.<br /> <br /> Because ipv4_net_table does not use designated initializers, there is no<br /> easy way to fix up this one "bad" table entry. However, the data pointer<br /> updating logic shouldn&amp;#39;t be applied to NULL pointers anyway, so we<br /> instead force these entries to be read-only.<br /> <br /> These sysctls used to exist in ipv4_table (init-net only), but they were<br /> moved to the per-net ipv4_net_table, presumably without realizing that<br /> tcp_allowed_congestion_control was writable and thus introduced a leak.<br /> <br /> Because the intent of that commit was only to know (i.e. read) "which<br /> congestion algorithms are available or allowed", this read-only solution<br /> should be sufficient.<br /> <br /> The logic added in recent commit<br /> 31c4d2f160eb: ("net: Ensure net namespace isolation of sysctls")<br /> does not and cannot check for NULL data pointers, because<br /> other table entries (e.g. /proc/sys/net/netfilter/nf_log/) have<br /> .data=NULL but use other methods (.extra2) to access the struct net.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nftables: clone set element expression template<br /> <br /> memcpy() breaks when using connlimit in set elements. Use<br /> nft_expr_clone() to initialize the connlimit expression list, otherwise<br /> connlimit garbage collector crashes when walking on the list head copy.<br /> <br /> [ 493.064656] Workqueue: events_power_efficient nft_rhash_gc [nf_tables]<br /> [ 493.064685] RIP: 0010:find_or_evict+0x5a/0x90 [nf_conncount]<br /> [ 493.064694] Code: 2b 43 40 83 f8 01 77 0d 48 c7 c0 f5 ff ff ff 44 39 63 3c 75 df 83 6d 18 01 48 8b 43 08 48 89 de 48 8b 13 48 8b 3d ee 2f 00 00 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 03 48 83<br /> [ 493.064699] RSP: 0018:ffffc90000417dc0 EFLAGS: 00010297<br /> [ 493.064704] RAX: 0000000000000000 RBX: ffff888134f38410 RCX: 0000000000000000<br /> [ 493.064708] RDX: 0000000000000000 RSI: ffff888134f38410 RDI: ffff888100060cc0<br /> [ 493.064711] RBP: ffff88812ce594a8 R08: ffff888134f38438 R09: 00000000ebb9025c<br /> [ 493.064714] R10: ffffffff8219f838 R11: 0000000000000017 R12: 0000000000000001<br /> [ 493.064718] R13: ffffffff82146740 R14: ffff888134f38410 R15: 0000000000000000<br /> [ 493.064721] FS: 0000000000000000(0000) GS:ffff88840e440000(0000) knlGS:0000000000000000<br /> [ 493.064725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 493.064729] CR2: 0000000000000008 CR3: 00000001330aa002 CR4: 00000000001706e0<br /> [ 493.064733] Call Trace:<br /> [ 493.064737] nf_conncount_gc_list+0x8f/0x150 [nf_conncount]<br /> [ 493.064746] nft_rhash_gc+0x106/0x390 [nf_tables]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: fix unbalanced device enable/disable in suspend/resume<br /> <br /> pci_disable_device() called in __ixgbe_shutdown() decreases<br /> dev-&gt;enable_cnt by 1. pci_enable_device_mem() which increases<br /> dev-&gt;enable_cnt by 1, was removed from ixgbe_resume() in commit<br /> 6f82b2558735 ("ixgbe: use generic power management"). This caused<br /> unbalanced increase/decrease. So add pci_enable_device_mem() back.<br /> <br /> Fix the following call trace.<br /> <br /> ixgbe 0000:17:00.1: disabling already-disabled device<br /> Call Trace:<br /> __ixgbe_shutdown+0x10a/0x1e0 [ixgbe]<br /> ixgbe_suspend+0x32/0x70 [ixgbe]<br /> pci_pm_suspend+0x87/0x160<br /> ? pci_pm_freeze+0xd0/0xd0<br /> dpm_run_callback+0x42/0x170<br /> __device_suspend+0x114/0x460<br /> async_suspend+0x1f/0xa0<br /> async_run_entry_fn+0x3c/0xf0<br /> process_one_work+0x1dd/0x410<br /> worker_thread+0x34/0x3f0<br /> ? cancel_delayed_work+0x90/0x90<br /> kthread+0x14c/0x170<br /> ? kthread_park+0x90/0x90<br /> ret_from_fork+0x1f/0x30

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.