Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix NULL pointer dereference in iavf_get_link_ksettings<br /> <br /> Fix possible NULL pointer dereference, due to freeing of adapter-&gt;vf_res<br /> in iavf_init_get_resources. Previous commit introduced a regression,<br /> where receiving IAVF_ERR_ADMIN_QUEUE_NO_WORK from iavf_get_vf_config<br /> would free adapter-&gt;vf_res. However, netdev is still registered, so<br /> ethtool_ops can be called. Calling iavf_get_link_ksettings with no vf_res,<br /> will result with:<br /> [ 9385.242676] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [ 9385.242683] #PF: supervisor read access in kernel mode<br /> [ 9385.242686] #PF: error_code(0x0000) - not-present page<br /> [ 9385.242690] PGD 0 P4D 0<br /> [ 9385.242696] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI<br /> [ 9385.242701] CPU: 6 PID: 3217 Comm: pmdalinux Kdump: loaded Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1<br /> [ 9385.242708] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019<br /> [ 9385.242710] RIP: 0010:iavf_get_link_ksettings+0x29/0xd0 [iavf]<br /> [ 9385.242745] Code: 00 0f 1f 44 00 00 b8 01 ef ff ff 48 c7 46 30 00 00 00 00 48 c7 46 38 00 00 00 00 c6 46 0b 00 66 89 46 08 48 8b 87 68 0e 00 00 40 08 80 75 50 8b 87 5c 0e 00 00 83 f8 08 74 7a 76 1d 83 f8 20<br /> [ 9385.242749] RSP: 0018:ffffc0560ec7fbd0 EFLAGS: 00010246<br /> [ 9385.242755] RAX: 0000000000000000 RBX: ffffc0560ec7fc08 RCX: 0000000000000000<br /> [ 9385.242759] RDX: ffffffffc0ad4550 RSI: ffffc0560ec7fc08 RDI: ffffa0fc66674000<br /> [ 9385.242762] RBP: 00007ffd1fb2bf50 R08: b6a2d54b892363ee R09: ffffa101dc14fb00<br /> [ 9385.242765] R10: 0000000000000000 R11: 0000000000000004 R12: ffffa0fc66674000<br /> [ 9385.242768] R13: 0000000000000000 R14: ffffa0fc66674000 R15: 00000000ffffffa1<br /> [ 9385.242771] FS: 00007f93711a2980(0000) GS:ffffa0fad72c0000(0000) knlGS:0000000000000000<br /> [ 9385.242775] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 9385.242778] CR2: 0000000000000008 CR3: 0000000a8e61c003 CR4: 00000000003706e0<br /> [ 9385.242781] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 9385.242784] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 9385.242787] Call Trace:<br /> [ 9385.242791] <br /> [ 9385.242793] ethtool_get_settings+0x71/0x1a0<br /> [ 9385.242814] __dev_ethtool+0x426/0x2f40<br /> [ 9385.242823] ? slab_post_alloc_hook+0x4f/0x280<br /> [ 9385.242836] ? kmem_cache_alloc_trace+0x15d/0x2f0<br /> [ 9385.242841] ? dev_ethtool+0x59/0x170<br /> [ 9385.242848] dev_ethtool+0xa7/0x170<br /> [ 9385.242856] dev_ioctl+0xc3/0x520<br /> [ 9385.242866] sock_do_ioctl+0xa0/0xe0<br /> [ 9385.242877] sock_ioctl+0x22f/0x320<br /> [ 9385.242885] __x64_sys_ioctl+0x84/0xc0<br /> [ 9385.242896] do_syscall_64+0x3a/0x80<br /> [ 9385.242904] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 9385.242918] RIP: 0033:0x7f93702396db<br /> [ 9385.242923] Code: 73 01 c3 48 8b 0d ad 57 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 57 38 00 f7 d8 64 89 01 48<br /> [ 9385.242927] RSP: 002b:00007ffd1fb2bf18 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> [ 9385.242932] RAX: ffffffffffffffda RBX: 000055671b1d2fe0 RCX: 00007f93702396db<br /> [ 9385.242935] RDX: 00007ffd1fb2bf20 RSI: 0000000000008946 RDI: 0000000000000007<br /> [ 9385.242937] RBP: 00007ffd1fb2bf20 R08: 0000000000000003 R09: 0030763066307330<br /> [ 9385.242940] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd1fb2bf80<br /> [ 9385.242942] R13: 0000000000000007 R14: 0000556719f6de90 R15: 00007ffd1fb2c1b0<br /> [ 9385.242948] <br /> [ 9385.242949] Modules linked in: iavf(E) xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nft_compat nf_nat_tftp nft_objref nf_conntrack_tftp bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink vfat fat irdma ib_uverbs ib_core intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretem<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix adminq error handling<br /> <br /> iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent<br /> memory for VF mailbox.<br /> Free DMA regions for both ASQ and ARQ in case error happens during<br /> configuration of ASQ/ARQ registers.<br /> Without this change it is possible to see when unloading interface:<br /> 74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32]<br /> One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix reset error handling<br /> <br /> Do not call iavf_close in iavf_reset_task error handling. Doing so can<br /> lead to double call of napi_disable, which can lead to deadlock there.<br /> Removing VF would lead to iavf_remove task being stuck, because it<br /> requires crit_lock, which is held by iavf_close.<br /> Call iavf_disable_vf if reset fail, so that driver will clean up<br /> remaining invalid resources.<br /> During rapid VF resets, HW can fail to setup VF mailbox. Wrong<br /> error handling can lead to iavf_remove being stuck with:<br /> [ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53<br /> ...<br /> [ 5267.189211] INFO: task repro.sh:11219 blocked for more than 30 seconds.<br /> [ 5267.189520] Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1<br /> [ 5267.189764] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 5267.190062] task:repro.sh state:D stack: 0 pid:11219 ppid: 8162 flags:0x00000000<br /> [ 5267.190347] Call Trace:<br /> [ 5267.190647] <br /> [ 5267.190927] __schedule+0x460/0x9f0<br /> [ 5267.191264] schedule+0x44/0xb0<br /> [ 5267.191563] schedule_preempt_disabled+0x14/0x20<br /> [ 5267.191890] __mutex_lock.isra.12+0x6e3/0xac0<br /> [ 5267.192237] ? iavf_remove+0xf9/0x6c0 [iavf]<br /> [ 5267.192565] iavf_remove+0x12a/0x6c0 [iavf]<br /> [ 5267.192911] ? _raw_spin_unlock_irqrestore+0x1e/0x40<br /> [ 5267.193285] pci_device_remove+0x36/0xb0<br /> [ 5267.193619] device_release_driver_internal+0xc1/0x150<br /> [ 5267.193974] pci_stop_bus_device+0x69/0x90<br /> [ 5267.194361] pci_stop_and_remove_bus_device+0xe/0x20<br /> [ 5267.194735] pci_iov_remove_virtfn+0xba/0x120<br /> [ 5267.195130] sriov_disable+0x2f/0xe0<br /> [ 5267.195506] ice_free_vfs+0x7d/0x2f0 [ice]<br /> [ 5267.196056] ? pci_get_device+0x4f/0x70<br /> [ 5267.196496] ice_sriov_configure+0x78/0x1a0 [ice]<br /> [ 5267.196995] sriov_numvfs_store+0xfe/0x140<br /> [ 5267.197466] kernfs_fop_write_iter+0x12e/0x1c0<br /> [ 5267.197918] new_sync_write+0x10c/0x190<br /> [ 5267.198404] vfs_write+0x24e/0x2d0<br /> [ 5267.198886] ksys_write+0x5c/0xd0<br /> [ 5267.199367] do_syscall_64+0x3a/0x80<br /> [ 5267.199827] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 5267.200317] RIP: 0033:0x7f5b381205c8<br /> [ 5267.200814] RSP: 002b:00007fff8c7e8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 5267.201981] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f5b381205c8<br /> [ 5267.202620] RDX: 0000000000000002 RSI: 00005569420ee900 RDI: 0000000000000001<br /> [ 5267.203426] RBP: 00005569420ee900 R08: 000000000000000a R09: 00007f5b38180820<br /> [ 5267.204327] R10: 000000000000000a R11: 0000000000000246 R12: 00007f5b383c06e0<br /> [ 5267.205193] R13: 0000000000000002 R14: 00007f5b383bb880 R15: 0000000000000002<br /> [ 5267.206041] <br /> [ 5267.206970] Kernel panic - not syncing: hung_task: blocked tasks<br /> [ 5267.207809] CPU: 48 PID: 551 Comm: khungtaskd Kdump: loaded Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1<br /> [ 5267.208726] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019<br /> [ 5267.209623] Call Trace:<br /> [ 5267.210569] <br /> [ 5267.211480] dump_stack_lvl+0x33/0x42<br /> [ 5267.212472] panic+0x107/0x294<br /> [ 5267.213467] watchdog.cold.8+0xc/0xbb<br /> [ 5267.214413] ? proc_dohung_task_timeout_secs+0x30/0x30<br /> [ 5267.215511] kthread+0xf4/0x120<br /> [ 5267.216459] ? kthread_complete_and_exit+0x20/0x20<br /> [ 5267.217505] ret_from_fork+0x22/0x30<br /> [ 5267.218459]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pci: Fix get_phb_number() locking<br /> <br /> The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP<br /> warning on some systems:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> 1 lock held by swapper/1:<br /> #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220<br /> Preemption disabled at:<br /> [] 0x0<br /> CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1<br /> Call Trace:<br /> [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable)<br /> [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8<br /> [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec<br /> [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4<br /> [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220<br /> [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784<br /> [d101de50] [c140852c] discover_phbs+0x30/0x4c<br /> [d101de60] [c0007fd4] do_one_initcall+0x94/0x344<br /> [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c<br /> [d101df10] [c00086e0] kernel_init+0x34/0x160<br /> [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64<br /> <br /> This is because pcibios_alloc_controller() holds hose_spinlock but<br /> of_alias_get_id() takes of_mutex which can sleep.<br /> <br /> The hose_spinlock protects the phb_bitmap, and also the hose_list, but<br /> it doesn&amp;#39;t need to be held while get_phb_number() calls the OF routines,<br /> because those are only looking up information in the device tree.<br /> <br /> So fix it by having get_phb_number() take the hose_spinlock itself, only<br /> where required, and then dropping the lock before returning.<br /> pcibios_alloc_controller() then needs to take the lock again before the<br /> list_add() but that&amp;#39;s safe, the order of the list is not important.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change()<br /> <br /> The issue happens on some error handling paths. When the function<br /> fails to grab the object `xprt`, it simply returns 0, forgetting to<br /> decrease the reference count of another object `xps`, which is<br /> increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount<br /> leaks. Also, the function forgets to check whether `xps` is valid<br /> before using it, which may result in NULL-dereferencing issues.<br /> <br /> Fix it by adding proper error handling code when either `xprt` or<br /> `xps` is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: mv88e6060: prevent crash on an unused port<br /> <br /> If the port isn&amp;#39;t a CPU port nor a user port, &amp;#39;cpu_dp&amp;#39;<br /> is a null pointer and a crash happened on dereferencing<br /> it in mv88e6060_setup_port():<br /> <br /> [ 9.575872] Unable to handle kernel NULL pointer dereference at virtual address 00000014<br /> ...<br /> [ 9.942216] mv88e6060_setup from dsa_register_switch+0x814/0xe84<br /> [ 9.948616] dsa_register_switch from mdio_probe+0x2c/0x54<br /> [ 9.954433] mdio_probe from really_probe.part.0+0x98/0x2a0<br /> [ 9.960375] really_probe.part.0 from driver_probe_device+0x30/0x10c<br /> [ 9.967029] driver_probe_device from __device_attach_driver+0xb8/0x13c<br /> [ 9.973946] __device_attach_driver from bus_for_each_drv+0x90/0xe0<br /> [ 9.980509] bus_for_each_drv from __device_attach+0x110/0x184<br /> [ 9.986632] __device_attach from bus_probe_device+0x8c/0x94<br /> [ 9.992577] bus_probe_device from deferred_probe_work_func+0x78/0xa8<br /> [ 9.999311] deferred_probe_work_func from process_one_work+0x290/0x73c<br /> [ 10.006292] process_one_work from worker_thread+0x30/0x4b8<br /> [ 10.012155] worker_thread from kthread+0xd4/0x10c<br /> [ 10.017238] kthread from ret_from_fork+0x14/0x3c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: possible module reference underflow in error path<br /> <br /> dst-&gt;ops is set on when nft_expr_clone() fails, but module refcount has<br /> not been bumped yet, therefore nft_expr_destroy() leads to module<br /> reference underflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: DPCM: Don&amp;#39;t pick up BE without substream<br /> <br /> When DPCM tries to add valid BE connections at dpcm_add_paths(), it<br /> doesn&amp;#39;t check whether the picked BE actually supports for the given<br /> stream direction. Due to that, when an asymmetric BE stream is<br /> present, it picks up wrongly and this may result in a NULL dereference<br /> at a later point where the code assumes the existence of a<br /> corresponding BE substream.<br /> <br /> This patch adds the check for the presence of the substream for the<br /> target BE for avoiding the problem above.<br /> <br /> Note that we have already some fix for non-existing BE substream at<br /> commit 6246f283d5e0 ("ASoC: dpcm: skip missing substream while<br /> applying symmetry"). But the code path we&amp;#39;ve hit recently is rather<br /> happening before the previous fix. So this patch tries to fix at<br /> picking up a BE instead of parsing BE lists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()<br /> <br /> snprintf() returns the would-be-filled size when the string overflows<br /> the given buffer size, hence using this value may result in the buffer<br /> overflow (although it&amp;#39;s unrealistic).<br /> <br /> This patch replaces with a safer version, scnprintf() for papering<br /> over such a potential issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: debug: Fix potential buffer overflow by snprintf()<br /> <br /> snprintf() returns the would-be-filled size when the string overflows<br /> the given buffer size, hence using this value may result in the buffer<br /> overflow (although it&amp;#39;s unrealistic).<br /> <br /> This patch replaces with a safer version, scnprintf() for papering<br /> over such a potential issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: avs: Fix potential buffer overflow by snprintf()<br /> <br /> snprintf() returns the would-be-filled size when the string overflows<br /> the given buffer size, hence using this value may result in a buffer<br /> overflow (although it&amp;#39;s unrealistic).<br /> <br /> This patch replaces it with a safer version, scnprintf() for papering<br /> over such a potential issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix potential refcount leak in ndisc_router_discovery()<br /> <br /> The issue happens on specific paths in the function. After both the<br /> object `rt` and `neigh` are grabbed successfully, when `lifetime` is<br /> nonzero but the metric needs change, the function just deletes the<br /> route and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh`<br /> again if above conditions hold. The function simply overwrite `neigh`<br /> if succeeds or returns if fails, without decreasing the reference<br /> count of previous `neigh`. This may result in memory leaks.<br /> <br /> Fix it by decrementing the reference count of `neigh` in place.