Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: use get_random_u32 instead of prandom<br /> <br /> bh might occur while updating per-cpu rnd_state from user context,<br /> ie. local_out path.<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code: nginx/2725<br /> caller is nft_ng_random_eval+0x24/0x54 [nft_numgen]<br /> Call Trace:<br /> check_preemption_disabled+0xde/0xe0<br /> nft_ng_random_eval+0x24/0x54 [nft_numgen]<br /> <br /> Use the random driver instead, this also avoids need for local prandom<br /> state. Moreover, prandom now uses the random driver since d4150779e60f<br /> ("random32: use real rng for non-deterministic randomness").<br /> <br /> Based on earlier patch from Pablo Neira.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> filemap: Handle sibling entries in filemap_get_read_batch()<br /> <br /> If a read races with an invalidation followed by another read, it is<br /> possible for a folio to be replaced with a higher-order folio. If that<br /> happens, we&amp;#39;ll see a sibling entry for the new folio in the next iteration<br /> of the loop. This manifests as a NULL pointer dereference while holding<br /> the RCU read lock.<br /> <br /> Handle this by simply returning. The next call will find the new folio<br /> and handle it correctly. The other ways of handling this rare race are<br /> more complex and it&amp;#39;s just not worth it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: add missing TID updates on slab deactivation<br /> <br /> The fastpath in slab_alloc_node() assumes that c-&gt;slab is stable as long as<br /> the TID stays the same. However, two places in __slab_alloc() currently<br /> don&amp;#39;t update the TID when deactivating the CPU slab.<br /> <br /> If multiple operations race the right way, this could lead to an object<br /> getting lost; or, in an even more unlikely situation, it could even lead to<br /> an object being freed onto the wrong slab&amp;#39;s freelist, messing up the<br /> `inuse` counter and eventually causing a page to be freed to the page<br /> allocator while it still contains slab objects.<br /> <br /> (I haven&amp;#39;t actually tested these cases though, this is just based on<br /> looking at the code. Writing testcases for this stuff seems like it&amp;#39;d be<br /> a pain...)<br /> <br /> The race leading to state inconsistency is (all operations on the same CPU<br /> and kmem_cache):<br /> <br /> - task A: begin do_slab_free():<br /> - read TID<br /> - read pcpu freelist (==NULL)<br /> - check `slab == c-&gt;slab` (true)<br /> - [PREEMPT A-&gt;B]<br /> - task B: begin slab_alloc_node():<br /> - fastpath fails (`c-&gt;freelist` is NULL)<br /> - enter __slab_alloc()<br /> - slub_get_cpu_ptr() (disables preemption)<br /> - enter ___slab_alloc()<br /> - take local_lock_irqsave()<br /> - read c-&gt;freelist as NULL<br /> - get_freelist() returns NULL<br /> - write `c-&gt;slab = NULL`<br /> - drop local_unlock_irqrestore()<br /> - goto new_slab<br /> - slub_percpu_partial() is NULL<br /> - get_partial() returns NULL<br /> - slub_put_cpu_ptr() (enables preemption)<br /> - [PREEMPT B-&gt;A]<br /> - task A: finish do_slab_free():<br /> - this_cpu_cmpxchg_double() succeeds()<br /> - [CORRUPT STATE: c-&gt;slab==NULL, c-&gt;freelist!=NULL]<br /> <br /> From there, the object on c-&gt;freelist will get lost if task B is allowed to<br /> continue from here: It will proceed to the retry_load_slab label,<br /> set c-&gt;slab, then jump to load_freelist, which clobbers c-&gt;freelist.<br /> <br /> But if we instead continue as follows, we get worse corruption:<br /> <br /> - task A: run __slab_free() on object from other struct slab:<br /> - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial)<br /> - task A: run slab_alloc_node() with NUMA node constraint:<br /> - fastpath fails (c-&gt;slab is NULL)<br /> - call __slab_alloc()<br /> - slub_get_cpu_ptr() (disables preemption)<br /> - enter ___slab_alloc()<br /> - c-&gt;slab is NULL: goto new_slab<br /> - slub_percpu_partial() is non-NULL<br /> - set c-&gt;slab to slub_percpu_partial(c)<br /> - [CORRUPT STATE: c-&gt;slab points to slab-1, c-&gt;freelist has objects<br /> from slab-2]<br /> - goto redo<br /> - node_match() fails<br /> - goto deactivate_slab<br /> - existing c-&gt;freelist is passed into deactivate_slab()<br /> - inuse count of slab-1 is decremented to account for object from<br /> slab-2<br /> <br /> At this point, the inuse count of slab-1 is 1 lower than it should be.<br /> This means that if we free all allocated objects in slab-1 except for one,<br /> SLUB will think that slab-1 is completely unused, and may free its page,<br /> leading to use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ibmvfc: Allocate/free queue resource only during probe/remove<br /> <br /> Currently, the sub-queues and event pool resources are allocated/freed for<br /> every CRQ connection event such as reset and LPM. This exposes the driver<br /> to a couple issues. First the inefficiency of freeing and reallocating<br /> memory that can simply be resued after being sanitized. Further, a system<br /> under memory pressue runs the risk of allocation failures that could result<br /> in a crippled driver. Finally, there is a race window where command<br /> submission/compeletion can try to pull/return elements from/to an event<br /> pool that is being deleted or already has been deleted due to the lack of<br /> host state around freeing/allocating resources. The following is an example<br /> of list corruption following a live partition migration (LPM):<br /> <br /> Oops: Exception in kernel mode, sig: 5 [#1]<br /> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: vfat fat isofs cdrom ext4 mbcache jbd2 nft_counter nft_compat nf_tables nfnetlink rpadlpar_io rpaphp xsk_diag nfsv3 nfs_acl nfs lockd grace fscache netfs rfkill bonding tls sunrpc pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth vmx_crypto dm_multipath dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse<br /> CPU: 0 PID: 2108 Comm: ibmvfc_0 Kdump: loaded Not tainted 5.14.0-70.9.1.el9_0.ppc64le #1<br /> NIP: c0000000007c4bb0 LR: c0000000007c4bac CTR: 00000000005b9a10<br /> REGS: c00000025c10b760 TRAP: 0700 Not tainted (5.14.0-70.9.1.el9_0.ppc64le)<br /> MSR: 800000000282b033 CR: 2800028f XER: 0000000f<br /> CFAR: c0000000001f55bc IRQMASK: 0<br /> GPR00: c0000000007c4bac c00000025c10ba00 c000000002a47c00 000000000000004e<br /> GPR04: c0000031e3006f88 c0000031e308bd00 c00000025c10b768 0000000000000027<br /> GPR08: 0000000000000000 c0000031e3009dc0 00000031e0eb0000 0000000000000000<br /> GPR12: c0000031e2ffffa8 c000000002dd0000 c000000000187108 c00000020fcee2c0<br /> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> GPR20: 0000000000000000 0000000000000000 0000000000000000 c008000002f81300<br /> GPR24: 5deadbeef0000100 5deadbeef0000122 c000000263ba6910 c00000024cc88000<br /> GPR28: 000000000000003c c0000002430a0000 c0000002430ac300 000000000000c300<br /> NIP [c0000000007c4bb0] __list_del_entry_valid+0x90/0x100<br /> LR [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100<br /> Call Trace:<br /> [c00000025c10ba00] [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100 (unreliable)<br /> [c00000025c10ba60] [c008000002f42284] ibmvfc_free_queue+0xec/0x210 [ibmvfc]<br /> [c00000025c10bb10] [c008000002f4246c] ibmvfc_deregister_scsi_channel+0xc4/0x160 [ibmvfc]<br /> [c00000025c10bba0] [c008000002f42580] ibmvfc_release_sub_crqs+0x78/0x130 [ibmvfc]<br /> [c00000025c10bc20] [c008000002f4f6cc] ibmvfc_do_work+0x5c4/0xc70 [ibmvfc]<br /> [c00000025c10bce0] [c008000002f4fdec] ibmvfc_work+0x74/0x1e8 [ibmvfc]<br /> [c00000025c10bda0] [c0000000001872b8] kthread+0x1b8/0x1c0<br /> [c00000025c10be10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64<br /> Instruction dump:<br /> 40820034 38600001 38210060 4e800020 7c0802a6 7c641b78 3c62fe7a 7d254b78<br /> 3863b590 f8010070 4ba309cd 60000000 7c0802a6 3c62fe7a 3863b640<br /> ---[ end trace 11a2b65a92f8b66c ]---<br /> ibmvfc 30000003: Send warning. Receive queue closed, will retry.<br /> <br /> Add registration/deregistration helpers that are called instead during<br /> connection resets to sanitize and reconfigure the queues.

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

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xtensa: Fix refcount leak bug in time.c<br /> <br /> In calibrate_ccount(), of_find_compatible_node() will return a node<br /> pointer with refcount incremented. We should use of_node_put() when<br /> it is not used anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: adi-axi-adc: Fix refcount leak in adi_axi_adc_attach_client<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: aspeed: Fix refcount leak in aspeed_adc_set_trim_data<br /> <br /> of_find_node_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: trigger: sysfs: fix use-after-free on remove<br /> <br /> Ensure that the irq_work has completed before the trigger is freed.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in irq_work_run_list<br /> Read of size 8 at addr 0000000064702248 by task python3/25<br /> <br /> Call Trace:<br /> irq_work_run_list<br /> irq_work_tick<br /> update_process_times<br /> tick_sched_handle<br /> tick_sched_timer<br /> __hrtimer_run_queues<br /> hrtimer_interrupt<br /> <br /> Allocated by task 25:<br /> kmem_cache_alloc_trace<br /> iio_sysfs_trig_add<br /> dev_attr_store<br /> sysfs_kf_write<br /> kernfs_fop_write_iter<br /> new_sync_write<br /> vfs_write<br /> ksys_write<br /> sys_write<br /> <br /> Freed by task 25:<br /> kfree<br /> iio_sysfs_trig_remove<br /> dev_attr_store<br /> sysfs_kf_write<br /> kernfs_fop_write_iter<br /> new_sync_write<br /> vfs_write<br /> ksys_write<br /> sys_write<br /> <br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: fix list double add in uvcg_video_pump<br /> <br /> A panic can occur if the endpoint becomes disabled and the<br /> uvcg_video_pump adds the request back to the req_free list after it has<br /> already been queued to the endpoint. The endpoint complete will add the<br /> request back to the req_free list. Invalidate the local request handle<br /> once it&amp;#39;s been queued.<br /> <br /> [ 246.796704][T13726] configfs-gadget gadget: uvc: uvc_function_set_alt(1, 0)<br /> [ 246.797078][ T26] list_add double add: new=ffffff878bee5c40, prev=ffffff878bee5c40, next=ffffff878b0f0a90.<br /> [ 246.797213][ T26] ------------[ cut here ]------------<br /> [ 246.797224][ T26] kernel BUG at lib/list_debug.c:31!<br /> [ 246.807073][ T26] Call trace:<br /> [ 246.807180][ T26] uvcg_video_pump+0x364/0x38c<br /> [ 246.807366][ T26] process_one_work+0x2a4/0x544<br /> [ 246.807394][ T26] worker_thread+0x350/0x784<br /> [ 246.807442][ T26] kthread+0x2ac/0x320

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix dynamic root getattr<br /> <br /> The recent patch to make afs_getattr consult the server didn&amp;#39;t account<br /> for the pseudo-inodes employed by the dynamic root-type afs superblock<br /> not having a volume or a server to access, and thus an oops occurs if<br /> such a directory is stat&amp;#39;d.<br /> <br /> Fix this by checking to see if the vnode-&gt;volume pointer actually points<br /> anywhere before following it in afs_getattr().<br /> <br /> This can be tested by stat&amp;#39;ing a directory in /afs. It may be<br /> sufficient just to do "ls /afs" and the oops looks something like:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> ...<br /> RIP: 0010:afs_getattr+0x8b/0x14b<br /> ...<br /> Call Trace:<br /> <br /> vfs_statx+0x79/0xf5<br /> vfs_fstatat+0x49/0x62