Vulnerabilities

In mupen64plus v2.6.0 there is an array overflow vulnerability in the write_rdram_regs and write_rdram_regs functions, which enables executing arbitrary commands on the host machine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ti: j721e-csi2rx: fix list_del corruption<br /> <br /> If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is<br /> marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue.<br /> This causes the same buffer to be retried in the next iteration, resulting<br /> in a double list_del() and eventual list corruption.<br /> <br /> Fix this by removing the buffer from the queue before calling<br /> vb2_buffer_done() on error.<br /> <br /> This resolves a crash due to list_del corruption:<br /> [ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA<br /> [ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048<br /> [ 37.839761] list_del corruption. next-&gt;prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428)<br /> [ 37.850799] ------------[ cut here ]------------<br /> [ 37.855424] kernel BUG at lib/list_debug.c:65!<br /> [ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul<br /> [ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY<br /> [ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT)<br /> [ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114<br /> [ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114<br /> [ 37.914059] sp : ffff800080003db0<br /> [ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000<br /> [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122<br /> [ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0<br /> [ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a<br /> [ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720<br /> [ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea<br /> [ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568<br /> [ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff<br /> [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d<br /> [ 37.988832] Call trace:<br /> [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P)<br /> [ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4<br /> [ 38.001419] udma_vchan_complete+0x1e0/0x344<br /> [ 38.005705] tasklet_action_common+0x118/0x310<br /> [ 38.010163] tasklet_action+0x30/0x3c<br /> [ 38.013832] handle_softirqs+0x10c/0x2e0<br /> [ 38.017761] __do_softirq+0x14/0x20<br /> [ 38.021256] ____do_softirq+0x10/0x20<br /> [ 38.024931] call_on_irq_stack+0x24/0x60<br /> [ 38.028873] do_softirq_own_stack+0x1c/0x40<br /> [ 38.033064] __irq_exit_rcu+0x130/0x15c<br /> [ 38.036909] irq_exit_rcu+0x10/0x20<br /> [ 38.040403] el1_interrupt+0x38/0x60<br /> [ 38.043987] el1h_64_irq_handler+0x18/0x24<br /> [ 38.048091] el1h_64_irq+0x6c/0x70<br /> [ 38.051501] default_idle_call+0x34/0xe0 (P)<br /> [ 38.055783] do_idle+0x1f8/0x250<br /> [ 38.059021] cpu_startup_entry+0x34/0x3c<br /> [ 38.062951] rest_init+0xb4/0xc0<br /> [ 38.066186] console_on_rootfs+0x0/0x6c<br /> [ 38.070031] __primary_switched+0x88/0x90<br /> [ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000)<br /> [ 38.080168] ---[ end trace 0000000000000000 ]---<br /> [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt<br /> [ 38.092197] SMP: stopping secondary CPUs<br /> [ 38.096139] Kernel Offset: disabled<br /> [ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b<br /> [ 38.105202] Memory Limit: none<br /> [ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zloop: fix KASAN use-after-free of tag set<br /> <br /> When a zoned loop device, or zloop device, is removed, KASAN enabled<br /> kernel reports "BUG KASAN use-after-free" in blk_mq_free_tag_set(). The<br /> BUG happens because zloop_ctl_remove() calls put_disk(), which invokes<br /> zloop_free_disk(). The zloop_free_disk() frees the memory allocated for<br /> the zlo pointer. However, after the memory is freed, zloop_ctl_remove()<br /> calls blk_mq_free_tag_set(&amp;zlo-&gt;tag_set), which accesses the freed zlo.<br /> Hence the KASAN use-after-free.<br /> <br /> zloop_ctl_remove()<br /> put_disk(zlo-&gt;disk)<br /> put_device()<br /> kobject_put()<br /> ...<br /> zloop_free_disk()<br /> kvfree(zlo)<br /> blk_mq_free_tag_set(&amp;zlo-&gt;tag_set)<br /> <br /> To avoid the BUG, move the call to blk_mq_free_tag_set(&amp;zlo-&gt;tag_set)<br /> from zloop_ctl_remove() into zloop_free_disk(). This ensures that<br /> the tag_set is freed before the call to kvfree(zlo).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: make rdev_addable usable for rcu mode<br /> <br /> Our testcase trigger panic:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000e0<br /> ...<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94<br /> PREEMPT(none)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.16.1-2.fc37 04/01/2014<br /> Workqueue: md_misc md_start_sync<br /> RIP: 0010:rdev_addable+0x4d/0xf0<br /> ...<br /> Call Trace:<br /> <br /> md_start_sync+0x329/0x480<br /> process_one_work+0x226/0x6d0<br /> worker_thread+0x19e/0x340<br /> kthread+0x10f/0x250<br /> ret_from_fork+0x14d/0x180<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Modules linked in: raid10<br /> CR2: 00000000000000e0<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:rdev_addable+0x4d/0xf0<br /> <br /> md_spares_need_change in md_start_sync will call rdev_addable which<br /> protected by rcu_read_lock/rcu_read_unlock. This rcu context will help<br /> protect rdev won&amp;#39;t be released, but rdev-&gt;mddev will be set to NULL<br /> before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by<br /> using READ_ONCE and check does rdev-&gt;mddev still alive.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: pnv_php: Clean up allocated IRQs on unplug<br /> <br /> When the root of a nested PCIe bridge configuration is unplugged, the<br /> pnv_php driver leaked the allocated IRQ resources for the child bridges&amp;#39;<br /> hotplug event notifications, resulting in a panic.<br /> <br /> Fix this by walking all child buses and deallocating all its IRQ resources<br /> before calling pci_hp_remove_devices().<br /> <br /> Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so<br /> that it is only destroyed in pnv_php_free_slot(), instead of<br /> pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will<br /> now be called by workers triggered by hot unplug interrupts, so the<br /> workqueue needs to stay allocated.<br /> <br /> The abridged kernel panic that occurs without this patch is as follows:<br /> <br /> WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c<br /> CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2<br /> Call Trace:<br /> msi_device_data_release+0x34/0x9c (unreliable)<br /> release_nodes+0x64/0x13c<br /> devres_release_all+0xc0/0x140<br /> device_del+0x2d4/0x46c<br /> pci_destroy_dev+0x5c/0x194<br /> pci_hp_remove_devices+0x90/0x128<br /> pci_hp_remove_devices+0x44/0x128<br /> pnv_php_disable_slot+0x54/0xd4<br /> power_write_file+0xf8/0x18c<br /> pci_slot_attr_store+0x40/0x5c<br /> sysfs_kf_write+0x64/0x78<br /> kernfs_fop_write_iter+0x1b0/0x290<br /> vfs_write+0x3bc/0x50c<br /> ksys_write+0x84/0x140<br /> system_call_exception+0x124/0x230<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> [bhelgaas: tidy comments]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: pnv_php: Fix surprise plug detection and recovery<br /> <br /> The existing PowerNV hotplug code did not handle surprise plug events<br /> correctly, leading to a complete failure of the hotplug system after device<br /> removal and a required reboot to detect new devices.<br /> <br /> This comes down to two issues:<br /> <br /> 1) When a device is surprise removed, often the bridge upstream<br /> port will cause a PE freeze on the PHB. If this freeze is not<br /> cleared, the MSI interrupts from the bridge hotplug notification<br /> logic will not be received by the kernel, stalling all plug events<br /> on all slots associated with the PE.<br /> <br /> 2) When a device is removed from a slot, regardless of surprise or<br /> programmatic removal, the associated PHB/PE ls left frozen.<br /> If this freeze is not cleared via a fundamental reset, skiboot<br /> is unable to clear the freeze and cannot retrain / rescan the<br /> slot. This also requires a reboot to clear the freeze and redetect<br /> the device in the slot.<br /> <br /> Issue the appropriate unfreeze and rescan commands on hotplug events,<br /> and don&amp;#39;t oops on hotplug if pci_bus_to_OF_node() returns NULL.<br /> <br /> [bhelgaas: tidy comments]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: drop UFO packets in udp_rcv_segment()<br /> <br /> When sending a packet with virtio_net_hdr to tun device, if the gso_type<br /> in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr<br /> size, below crash may happen.<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:4572!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:skb_pull_rcsum+0x8e/0xa0<br /> Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc 0b 0f 0b 66 66 2e 0f 1f 84 00 000<br /> RSP: 0018:ffffc900001fba38 EFLAGS: 00000297<br /> RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948<br /> RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062<br /> RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001<br /> R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000<br /> R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900<br /> FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445<br /> udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475<br /> udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626<br /> __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690<br /> ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233<br /> ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579<br /> ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636<br /> ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670<br /> __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067<br /> netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210<br /> napi_complete_done+0x78/0x180 net/core/dev.c:6580<br /> tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909<br /> tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984<br /> vfs_write+0x300/0x420 fs/read_write.c:593<br /> ksys_write+0x60/0xd0 fs/read_write.c:686<br /> do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63<br /> <br /> <br /> To trigger gso segment in udp_queue_rcv_skb(), we should also set option<br /> UDP_ENCAP_ESPINUDP to enable udp_sk(sk)-&gt;encap_rcv. When the encap_rcv<br /> hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try<br /> to pull udphdr, but the skb size has been segmented to gso size, which<br /> leads to this crash.<br /> <br /> Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")<br /> introduces segmentation in UDP receive path only for GRO, which was never<br /> intended to be used for UFO, so drop UFO packets in udp_rcv_segment().

spimsimulator spim v9.1.24 and before is vulnerable to Buffer Overflow in READ_STRING_SYSCALL.

IBM QRadar SIEM 7.5 through 7.5.0 UP13 could allow an authenticated user to escalate their privileges via a misconfigured cronjob due to execution with unnecessary privileges.

IBM QRadar SIEM 7.5 through 7.5.0 Dashboard is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

QuantumNous new-api v.0.8.5.2 is vulnerable to Cross Site Scripting (XSS).

MCSManager 10.5.3 daemon process runs as a root account by default, and its sensitive data (including tokens and terminal content) is stored in the data directory, readable by all users. Other users on the system can read the daemon&amp;#39;s key and use it to log in, leading to privilege escalation.