CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-45009 – mptcp: pm: only decrement add_addr_accepted for MPJ req
https://notcve.org/view.php?id=CVE-2024-45009
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only decrement add_addr_accepted for MPJ req Adding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest. Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR. A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR. • https://git.kernel.org/stable/c/d0876b2284cf8b34dd214b2d0aa21071c345da59 https://git.kernel.org/stable/c/35b31f5549ede4070566b949781e83495906b43d https://git.kernel.org/stable/c/85b866e4c4e63a1d7afb58f1e24273caad03d0b7 https://git.kernel.org/stable/c/d20bf2c96d7ffd171299b32f562f70e5bf5dc608 https://git.kernel.org/stable/c/2060f1efab370b496c4903b840844ecaff324c3c https://git.kernel.org/stable/c/1c1f721375989579e46741f59523e39ec9b2a9bd •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45008 – Input: MT - limit max slots
https://notcve.org/view.php?id=CVE-2024-45008
In the Linux kernel, the following vulnerability has been resolved: Input: MT - limit max slots syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE). Since nobody knows possible max slots, this patch chose 1024. • https://git.kernel.org/stable/c/2829c80614890624456337e47320289112785f3e https://git.kernel.org/stable/c/87f610a1a7fbdb1f2e3d90b54c955bd3b8a0c322 https://git.kernel.org/stable/c/05dd9aabd04f9b5eb04dab9bb83d8c3e982d7549 https://git.kernel.org/stable/c/95f73d01f547dfc67fda3022c51e377a0454b505 https://git.kernel.org/stable/c/94736334b8a25e4fae8daa6934e54a31f099be43 https://git.kernel.org/stable/c/8f04edd554d191834e9e1349ef030318ea6b11ba https://git.kernel.org/stable/c/cd19f1799c32ba7b874474b1b968815ce5364f73 https://git.kernel.org/stable/c/99d3bf5f7377d42f8be60a6b9cb60fb0b •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-45007 – char: xillybus: Don't destroy workqueue from work item running on it
https://notcve.org/view.php?id=CVE-2024-45007
In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Don't destroy workqueue from work item running on it Triggered by a kref decrement, destroy_workqueue() may be called from within a work item for destroying its own workqueue. This illegal situation is averted by adding a module-global workqueue for exclusive use of the offending work item. Other work items continue to be queued on per-device workqueues to ensure performance. • https://git.kernel.org/stable/c/409b495f8e3300d5fba08bc817fa8825dae48cc9 https://git.kernel.org/stable/c/5d3567caff2a1d678aa40cc74a54e1318941fad3 https://git.kernel.org/stable/c/a7ad105b12256ec7fb6d6d1a0e2e60f00b7da157 https://git.kernel.org/stable/c/aa1a19724fa2c31e97a9be48baedd4692b265157 https://git.kernel.org/stable/c/ccbde4b128ef9c73d14d0d7817d68ef795f6d131 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45006 – xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration
https://notcve.org/view.php?id=CVE-2024-45006
In the Linux kernel, the following vulnerability has been resolved: xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference. Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usb_ep0_reinit() in this case, which ends up calling xhci_configure_endpoint(). On Panther point xHC the xhci_configure_endpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware If xHC address device command fails then a new xhci_virt_device structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usb_ep0_reinit() is called and xhci_configure_endpoint() tries to check and reserve bandwidth [46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: error_code(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated. • https://git.kernel.org/stable/c/651aaf36a7d7b36a58980e70133f9437d4f6d312 https://git.kernel.org/stable/c/ef0a0e616b2789bb804a0ce5e161db03170a85b6 https://git.kernel.org/stable/c/a57b0ebabe6862dce0a2e0f13e17941ad72fc56b https://git.kernel.org/stable/c/0f0654318e25b2c185e245ba4a591e42fabb5e59 https://git.kernel.org/stable/c/365ef7c4277fdd781a695c3553fa157d622d805d https://git.kernel.org/stable/c/5ad898ae82412f8a689d59829804bff2999dd0ea https://git.kernel.org/stable/c/6b99de301d78e1f5249e57ef2c32e1dec3df2bb1 https://git.kernel.org/stable/c/8fb9d412ebe2f245f13481e4624b40e65 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-45005 – KVM: s390: fix validity interception issue when gisa is switched off
https://notcve.org/view.php?id=CVE-2024-45005
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix validity interception issue when gisa is switched off We might run into a SIE validity if gisa has been disabled either via using kernel parameter "kvm.use_gisa=0" or by setting the related sysfs attribute to N (echo N >/sys/module/kvm/parameters/use_gisa). The validity is caused by an invalid value in the SIE control block's gisa designation. That happens because we pass the uninitialized gisa origin to virt_to_phys() before writing it to the gisa designation. To fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0. kvm_s390_get_gisa_desc() is used to determine which gisa designation to set in the SIE control block. A value of 0 in the gisa designation disables gisa usage. The issue surfaces in the host kernel with the following kernel message as soon a new kvm guest start is attemted. kvm: unhandled validity intercept 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm 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 sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118: c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 >000003d93deb0122: a728ffea lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1 000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call Trace: [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([<000003d93deb011e>] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm] [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm] [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm] [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70 [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0 [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0 [<000003d9be0f9a90>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003d9bd3c7f58>] __warn_printk+0xe8/0xf0 • https://git.kernel.org/stable/c/fe0ef00304639cae82df7c9ad6a15286bd5f876e https://git.kernel.org/stable/c/051c0a558154174cfcea301a386e4c91ade83ce1 https://git.kernel.org/stable/c/027ac3c5092561bccce09b314a73a1c167117ef6 https://git.kernel.org/stable/c/5a44bb061d04b0306f2aa8add761d86d152b9377 •