Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: fix NULL deref in ip_vs_add_service error path<br /> <br /> When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local<br /> variable sched is set to NULL. If ip_vs_start_estimator() subsequently<br /> fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched)<br /> with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL<br /> check (because svc-&gt;scheduler was set by the successful bind) but then<br /> dereferences the NULL sched parameter at sched-&gt;done_service, causing a<br /> kernel panic at offset 0x30 from NULL.<br /> <br /> Oops: general protection fault, [..] [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]<br /> RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69)<br /> Call Trace:<br /> <br /> ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500)<br /> do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809)<br /> nf_setsockopt (net/netfilter/nf_sockopt.c:102)<br /> [..]<br /> <br /> Fix by simply not clearing the local sched variable after a successful<br /> bind. ip_vs_unbind_scheduler() already detects whether a scheduler is<br /> installed via svc-&gt;scheduler, and keeping sched non-NULL ensures the<br /> error path passes the correct pointer to both ip_vs_unbind_scheduler()<br /> and ip_vs_scheduler_put().<br /> <br /> While the bug is older, the problem popups in more recent kernels (6.2),<br /> when the new error path is taken after the ip_vs_start_estimator() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: mcp23s08: Disable all pin interrupts during probe<br /> <br /> A chip being probed may have the interrupt-on-change feature enabled on<br /> some of its pins, for example after a reboot. This can cause the chip to<br /> generate interrupts for pins that don&amp;#39;t have a registered nested handler,<br /> which leads to a kernel crash such as below:<br /> <br /> [ 7.928897] Unable to handle kernel read from unreadable memory at virtual address 00000000000000ac<br /> [ 7.932314] Mem abort info:<br /> [ 7.935081] ESR = 0x0000000096000004<br /> [ 7.938808] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 7.944094] SET = 0, FnV = 0<br /> [ 7.947127] EA = 0, S1PTW = 0<br /> [ 7.950247] FSC = 0x04: level 0 translation fault<br /> [ 7.955101] Data abort info:<br /> [ 7.957961] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 7.963421] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 7.968447] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 7.973734] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000089b7000<br /> [ 7.980148] [00000000000000ac] pgd=0000000000000000, p4d=0000000000000000<br /> [ 7.986913] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 7.992545] Modules linked in:<br /> [ 8.073678] CPU: 0 UID: 0 PID: 81 Comm: irq/18-4-0025 Not tainted 7.0.0-rc6-gd2b5a1f931c8-dirty #199<br /> [ 8.073689] Hardware name: Khadas VIM3 (DT)<br /> [ 8.073692] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 8.094639] pc : _raw_spin_lock_irq+0x40/0x80<br /> [ 8.098970] lr : handle_nested_irq+0x2c/0x168<br /> [ 8.098979] sp : ffff800082b2bd20<br /> [ 8.106599] x29: ffff800082b2bd20 x28: ffff800080107920 x27: ffff800080104d88<br /> [ 8.106611] x26: ffff000003298080 x25: 0000000000000001 x24: 000000000000ff00<br /> [ 8.113707] x23: 0000000000000001 x22: 0000000000000000 x21: 000000000000000e<br /> [ 8.120850] x20: 0000000000000000 x19: 00000000000000ac x18: 0000000000000000<br /> [ 8.135046] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 8.135062] x14: ffff800081567ea8 x13: ffffffffffffffff x12: 0000000000000000<br /> [ 8.135070] x11: 00000000000000c0 x10: 0000000000000b60 x9 : ffff800080109e0c<br /> [ 8.135078] x8 : 1fffe0000069dbc1 x7 : 0000000000000001 x6 : ffff0000034ede00<br /> [ 8.135086] x5 : 0000000000000000 x4 : ffff0000034ede08 x3 : 0000000000000001<br /> [ 8.163460] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 00000000000000ac<br /> [ 8.170560] Call trace:<br /> [ 8.180094] _raw_spin_lock_irq+0x40/0x80 (P)<br /> [ 8.184443] mcp23s08_irq+0x248/0x358<br /> [ 8.184462] irq_thread_fn+0x34/0xb8<br /> [ 8.184470] irq_thread+0x1a4/0x310<br /> [ 8.195093] kthread+0x13c/0x150<br /> [ 8.198309] ret_from_fork+0x10/0x20<br /> [ 8.201850] Code: d65f03c0 d2800002 52800023 f9800011 (885ffc01)<br /> [ 8.207931] ---[ end trace 0000000000000000 ]---<br /> <br /> This issue has always been present, but has been latent until commit<br /> "f9f4fda15e72" ("pinctrl: mcp23s08: init reg_defaults from HW at probe and<br /> switch cache type"), which correctly removed reg_defaults from the regmap<br /> and as a side effect changed the behavior of the interrupt handler so that<br /> the real value of the MCP_GPINTEN register is now being read from the chip<br /> instead of using a bogus 0 default value; a non-zero value for this<br /> register can trigger the invocation of a nested handler which may not exist<br /> (yet).<br /> Fix this issue by disabling all pin interrupts during initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ioam6: fix OOB and missing lock<br /> <br /> When trace-&gt;type.bit6 is set:<br /> <br /> if (trace-&gt;type.bit6) {<br /> ...<br /> queue = skb_get_tx_queue(dev, skb);<br /> qdisc = rcu_dereference(queue-&gt;qdisc);<br /> <br /> This code can lead to an out-of-bounds access of the dev-&gt;_tx[] array<br /> when is_input is true. In such a case, the packet is on the RX path and<br /> skb-&gt;queue_mapping contains the RX queue index of the ingress device. If<br /> the ingress device has more RX queues than the egress device (dev) has<br /> TX queues, skb_get_queue_mapping(skb) will exceed dev-&gt;num_tx_queues.<br /> Add a check to avoid this situation since skb_get_tx_queue() does not<br /> clamp the index. This issue has also revealed that per queue visibility<br /> cannot be accurate and will be replaced later as a new feature.<br /> <br /> While at it, add missing lock around qdisc_qstats_qlen_backlog(). The<br /> function __ioam6_fill_trace_data() is called from both softirq and<br /> process contexts, hence the use of spin_lock_bh() here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_queue: make hash table per queue<br /> <br /> Sharing a global hash table among all queues is tempting, but<br /> it can cause crash:<br /> <br /> BUG: KASAN: slab-use-after-free in nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue]<br /> [..]<br /> nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue]<br /> nfnetlink_rcv_msg+0x46a/0x930<br /> kmem_cache_alloc_node_noprof+0x11e/0x450<br /> <br /> struct nf_queue_entry is freed via kfree, but parallel cpu can still<br /> encounter such an nf_queue_entry when walking the list.<br /> <br /> Alternative fix is to free the nf_queue_entry via kfree_rcu() instead,<br /> but as we have to alloc/free for each skb this will cause more mem<br /> pressure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel/uncore: Skip discovery table for offline dies<br /> <br /> This warning can be triggered if NUMA is disabled and the system<br /> boots with fewer CPUs than the number of CPUs in die 0.<br /> <br /> WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore]<br /> <br /> Currently, the discovery table continues to be parsed even if all CPUs<br /> in the associated die are offline. This can lead to an array overflow<br /> at "pmu-&gt;boxes[die] = box" in uncore_pci_pmu_register(), which may<br /> trigger the warning above or cause other issues.

Missing invocation of Servlet http web request method changeSessionId after session binding can be exploited for a session fixation attack in Apache Wicket.<br /> <br /> This issue affects Apache Wicket: from 8.0.0 through 8.17.0, 9.0.0, from 10.0.0 through 10.8.0.<br /> <br /> Users are recommended to upgrade to version 10.9.0, which fixes the issue.

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Apache Wicket.<br /> <br /> This issue affects Apache Wicket: from 8.0.0 through 8.17.0, 9.0.0, from 10.0.0 through 10.8.0.<br /> <br /> Users are recommended to upgrade to version 10.9.0, which fixes the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl<br /> <br /> When page reassignment was added to af_alg_pull_tsgl the original<br /> loop wasn&amp;#39;t updated so it may try to reassign one more page than<br /> necessary.<br /> <br /> Add the check to the reassignment so that this does not happen.<br /> <br /> Also update the comment which still refers to the obsolete offset<br /> argument.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: algif_aead - Fix minimum RX size check for decryption<br /> <br /> The check for the minimum receive buffer size did not take the<br /> tag size into account during decryption. Fix this by adding the<br /> required extra length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: validate inline data i_size during inode read<br /> <br /> When reading an inode from disk, ocfs2_validate_inode_block() performs<br /> various sanity checks but does not validate the size of inline data. If<br /> the filesystem is corrupted, an inode&amp;#39;s i_size can exceed the actual<br /> inline data capacity (id_count).<br /> <br /> This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data<br /> buffer, triggering a use-after-free when accessing directory entries from<br /> freed memory.<br /> <br /> In the syzbot report:<br /> - i_size was 1099511627576 bytes (~1TB)<br /> - Actual inline data capacity (id_count) is typically pos to jump out of bounds<br /> - This triggered a UAF in ocfs2_check_dir_entry()<br /> <br /> Fix by adding a validation check in ocfs2_validate_inode_block() to ensure<br /> inodes with inline data have i_size

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix out-of-bounds write in ocfs2_write_end_inline<br /> <br /> KASAN reports a use-after-free write of 4086 bytes in<br /> ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a<br /> copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on<br /> a loop device. The actual bug is an out-of-bounds write past the inode<br /> block buffer, not a true use-after-free. The write overflows into an<br /> adjacent freed page, which KASAN reports as UAF.<br /> <br /> The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk<br /> id_count field to determine whether a write fits in inline data. On a<br /> corrupted filesystem, id_count can exceed the physical maximum inline data<br /> capacity, causing writes to overflow the inode block buffer.<br /> <br /> Call trace (crash path):<br /> <br /> vfs_copy_file_range (fs/read_write.c:1634)<br /> do_splice_direct<br /> splice_direct_to_actor<br /> iter_file_splice_write<br /> ocfs2_file_write_iter<br /> generic_perform_write<br /> ocfs2_write_end<br /> ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949)<br /> ocfs2_write_end_inline (fs/ocfs2/aops.c:1915)<br /> memcpy_from_folio

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eventpoll: defer struct eventpoll free to RCU grace period<br /> <br /> In certain situations, ep_free() in eventpoll.c will kfree the epi-&gt;ep<br /> eventpoll struct while it still being used by another concurrent thread.<br /> Defer the kfree() to an RCU callback to prevent UAF.