ClassGraph before 4.8.112 was not resistant to XML eXternal Entity (XXE) attacks.

MISC:https://docs.r3.com/en/platform/corda/4.8/enterprise/release-notes-enterprise.html | MISC:https://github.com/classgraph/classgraph/commit/681362ad6b0b9d9abaffb2e07099ce54d7a41fa3 | MISC:https://github.com/classgraph/classgraph/pull/539 | MISC:https://github.com/classgraph/classgraph/releases/tag/classgraph-4.8.112

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: refactor malicious adv data check Check for out-of-bound read was being performed at the end of while num_reports loop, and would fill journal with false positives. Added check to beginning of loop processing so that it doesn't get checked after ptr has been advanced.

MISC:https://git.kernel.org/stable/c/305e92f525450f3e1b5f5c9dc7eadb152d66a082 | URL:https://git.kernel.org/stable/c/305e92f525450f3e1b5f5c9dc7eadb152d66a082 | MISC:https://git.kernel.org/stable/c/5a539c08d743d9910631448da78af5e961664c0e | URL:https://git.kernel.org/stable/c/5a539c08d743d9910631448da78af5e961664c0e | MISC:https://git.kernel.org/stable/c/5c968affa804ba98c3c603f37ffea6fba618025e | URL:https://git.kernel.org/stable/c/5c968affa804ba98c3c603f37ffea6fba618025e | MISC:https://git.kernel.org/stable/c/7889b38a7f21ed19314f83194622b195d328465c | URL:https://git.kernel.org/stable/c/7889b38a7f21ed19314f83194622b195d328465c | MISC:https://git.kernel.org/stable/c/835d3706852537bf92eb23eb8635b8dee0c0aa67 | URL:https://git.kernel.org/stable/c/835d3706852537bf92eb23eb8635b8dee0c0aa67 | MISC:https://git.kernel.org/stable/c/83d5196b65d1b29e27d7dd16a3b9b439fb1d2dba | URL:https://git.kernel.org/stable/c/83d5196b65d1b29e27d7dd16a3b9b439fb1d2dba | MISC:https://git.kernel.org/stable/c/8819f93cd4a443dfe547aa622b21f723757df3fb | URL:https://git.kernel.org/stable/c/8819f93cd4a443dfe547aa622b21f723757df3fb | MISC:https://git.kernel.org/stable/c/899663be5e75dc0174dc8bda0b5e6826edf0b29a | URL:https://git.kernel.org/stable/c/899663be5e75dc0174dc8bda0b5e6826edf0b29a | MISC:https://git.kernel.org/stable/c/bcea886771c3f22a590c8c8b9139a107bd7f1e1c | URL:https://git.kernel.org/stable/c/bcea886771c3f22a590c8c8b9139a107bd7f1e1c

In the Linux kernel, the following vulnerability has been resolved: i40e: Fix queues reservation for XDP When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference. i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e] Call Trace: ? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80 ? ata_qc_issue+0x107/0x1e0 ? lock_timer_base+0x61/0x80 ? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10 ? security_capable+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copy_from_user+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0 This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on. Fix this by always allocating last queue in PF queue pile for a flow director VSI.

MISC:https://git.kernel.org/stable/c/00eddb0e4ea115154581d1049507a996acfc2d3e | URL:https://git.kernel.org/stable/c/00eddb0e4ea115154581d1049507a996acfc2d3e | MISC:https://git.kernel.org/stable/c/4b3aa858268b7b9aeef02e5f9c4cd8f8fac101c8 | URL:https://git.kernel.org/stable/c/4b3aa858268b7b9aeef02e5f9c4cd8f8fac101c8 | MISC:https://git.kernel.org/stable/c/768eb705e6381f0c70ca29d4e66f19790d5d19a1 | URL:https://git.kernel.org/stable/c/768eb705e6381f0c70ca29d4e66f19790d5d19a1 | MISC:https://git.kernel.org/stable/c/92947844b8beee988c0ce17082b705c2f75f0742 | URL:https://git.kernel.org/stable/c/92947844b8beee988c0ce17082b705c2f75f0742 | MISC:https://git.kernel.org/stable/c/be6998f232b8e4ca8225029e305b8329d89bfd59 | URL:https://git.kernel.org/stable/c/be6998f232b8e4ca8225029e305b8329d89bfd59 | MISC:https://git.kernel.org/stable/c/d46fa4ea9756ef6cbcf9752d0832cc66e2d7121b | URL:https://git.kernel.org/stable/c/d46fa4ea9756ef6cbcf9752d0832cc66e2d7121b

In the Linux kernel, the following vulnerability has been resolved: ARM: 9170/1: fix panic when kasan and kprobe are enabled arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic. the kprobe emulate instruction function is distributed in three files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files. for example, use kprobe insert on cap_capable+20 after kasan enabled, the cap_capable assembly code is as follows: <cap_capable>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c add r0, r0, #108 ; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [pc, #144] ; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108] ; 0x6c e2859014 add r9, r5, #20 ...... The emulate_ldr assembly code after enabling kasan is as follows: c06f1384 <emulate_ldr>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c add r8, r2, #60 ; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f and sl, r5, #15 0a000001 beq c06f13bc <emulate_ldr+0x38> e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, r4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 add r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 1a000014 bne c06f1430 <emulate_ldr+0xac> e1a06000 mov r6, r0 e2840040 add r0, r4, #64 ; 0x40 ...... when running in emulate_ldr to simulate the ldr instruction, panic occurred, and the log is as follows: Unable to handle kernel NULL pointer dereference at virtual address 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, *pmd=00000000 Internal error: Oops: 206 [#1] SMP ARM PC is at cap_capable+0x14/0xb0 LR is at emulate_ldr+0x50/0xc0 psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit = 0xecd60190) (cap_capable) from (kprobe_handler+0x218/0x340) (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) (do_undefinstr) from (__und_svc_finish+0x0/0x30) (__und_svc_finish) from (cap_capable+0x18/0xb0) (cap_capable) from (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) from (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) from (copy_process.constprop.5+0x16b4/0x25c8) (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) (_do_fork) from (SyS_clone+0x1c/0x24) (SyS_clone) from (__sys_trace_return+0x0/0x10) Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)

MISC:https://git.kernel.org/stable/c/1515e72aae803fc6b466adf918e71c4e4c9d5b3d | URL:https://git.kernel.org/stable/c/1515e72aae803fc6b466adf918e71c4e4c9d5b3d | MISC:https://git.kernel.org/stable/c/8b59b0a53c840921b625378f137e88adfa87647e | URL:https://git.kernel.org/stable/c/8b59b0a53c840921b625378f137e88adfa87647e | MISC:https://git.kernel.org/stable/c/ba1863be105b06e10d0e2f6b1b8a0570801cfc71 | URL:https://git.kernel.org/stable/c/ba1863be105b06e10d0e2f6b1b8a0570801cfc71

In the Linux kernel, the following vulnerability has been resolved: PCI: pciehp: Fix infinite loop in IRQ handler upon power fault The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky: It can only be cleared after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot. The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots"). Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"): The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set. That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop. Fix by setting the power_fault_detected flag already in the hardirq handler.

MISC:https://git.kernel.org/stable/c/1db58c6584a72102e98af2e600ea184ddaf2b8af | URL:https://git.kernel.org/stable/c/1db58c6584a72102e98af2e600ea184ddaf2b8af | MISC:https://git.kernel.org/stable/c/23584c1ed3e15a6f4bfab8dc5a88d94ab929ee12 | URL:https://git.kernel.org/stable/c/23584c1ed3e15a6f4bfab8dc5a88d94ab929ee12 | MISC:https://git.kernel.org/stable/c/3b4c966fb156ff3e70b2526d964952ff7c1574d9 | URL:https://git.kernel.org/stable/c/3b4c966fb156ff3e70b2526d964952ff7c1574d9 | MISC:https://git.kernel.org/stable/c/464da38ba827f670deac6500a1de9a4f0f44c41d | URL:https://git.kernel.org/stable/c/464da38ba827f670deac6500a1de9a4f0f44c41d | MISC:https://git.kernel.org/stable/c/6d6f1f0dac3e3441ecdb1103d4efb11b9ed24dd5 | URL:https://git.kernel.org/stable/c/6d6f1f0dac3e3441ecdb1103d4efb11b9ed24dd5 | MISC:https://git.kernel.org/stable/c/ff27f7d0333cff89ec85c419f431aca1b38fb16a | URL:https://git.kernel.org/stable/c/ff27f7d0333cff89ec85c419f431aca1b38fb16a

In the Linux kernel, the following vulnerability has been resolved: RDMA: Fix use-after-free in rxe_queue_cleanup On error handling path in rxe_qp_from_init() qp->sq.queue is freed and then rxe_create_qp() will drop last reference to this object. qp clean up function will try to free this queue one time and it causes UAF bug. Fix it by zeroing queue pointer after freeing queue in rxe_qp_from_init().

MISC:https://git.kernel.org/stable/c/84b01721e8042cdd1e8ffeb648844a09cd4213e0 | URL:https://git.kernel.org/stable/c/84b01721e8042cdd1e8ffeb648844a09cd4213e0 | MISC:https://git.kernel.org/stable/c/acb53e47db1fbc7cd37ab10b46388f045a76e383 | URL:https://git.kernel.org/stable/c/acb53e47db1fbc7cd37ab10b46388f045a76e383

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow For the case of IB_MR_TYPE_DM the mr does doesn't have a umem, even though it is a user MR. This causes function mlx5_free_priv_descs() to think that it is a kernel MR, leading to wrongly accessing mr->descs that will get wrong values in the union which leads to attempt to release resources that were not allocated in the first place. For example: DMA-API: mlx5_core 0000:08:00.1: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=0 bytes] WARNING: CPU: 8 PID: 1021 at kernel/dma/debug.c:961 check_unmap+0x54f/0x8b0 RIP: 0010:check_unmap+0x54f/0x8b0 Call Trace: debug_dma_unmap_page+0x57/0x60 mlx5_free_priv_descs+0x57/0x70 [mlx5_ib] mlx5_ib_dereg_mr+0x1fb/0x3d0 [mlx5_ib] ib_dereg_mr_user+0x60/0x140 [ib_core] uverbs_destroy_uobject+0x59/0x210 [ib_uverbs] uobj_destroy+0x3f/0x80 [ib_uverbs] ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs] ? uverbs_finalize_object+0x50/0x50 [ib_uverbs] ? lock_acquire+0xc4/0x2e0 ? lock_acquired+0x12/0x380 ? lock_acquire+0xc4/0x2e0 ? lock_acquire+0xc4/0x2e0 ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs] ? lock_release+0x28a/0x400 ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs] ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs] __x64_sys_ioctl+0x7f/0xb0 do_syscall_64+0x38/0x90 Fix it by reorganizing the dereg flow and mlx5_ib_mr structure: - Move the ib_umem field into the user MRs structure in the union as it's applicable only there. - Function mlx5_ib_dereg_mr() will now call mlx5_free_priv_descs() only in case there isn't udata, which indicates that this isn't a user MR.

MISC:https://git.kernel.org/stable/c/c44979ace49b4aede3cc7cb5542316e53a4005c9 | URL:https://git.kernel.org/stable/c/c44979ace49b4aede3cc7cb5542316e53a4005c9 | MISC:https://git.kernel.org/stable/c/e3bc4d4b50cae7db08e50dbe43f771c906e97701 | URL:https://git.kernel.org/stable/c/e3bc4d4b50cae7db08e50dbe43f771c906e97701 | MISC:https://git.kernel.org/stable/c/f0ae4afe3d35e67db042c58a52909e06262b740f | URL:https://git.kernel.org/stable/c/f0ae4afe3d35e67db042c58a52909e06262b740f

In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix a user-after-free in add_pble_prm When irdma_hmc_sd_one fails, 'chunk' is freed while its still on the PBLE info list. Add the chunk entry to the PBLE info list only after successful setting of the SD in irdma_hmc_sd_one.

MISC:https://git.kernel.org/stable/c/11eebcf63e98fcf047a876a51d76afdabc3b8b9b | URL:https://git.kernel.org/stable/c/11eebcf63e98fcf047a876a51d76afdabc3b8b9b | MISC:https://git.kernel.org/stable/c/1e11a39a82e95ce86f849f40dda0d9c0498cebd9 | URL:https://git.kernel.org/stable/c/1e11a39a82e95ce86f849f40dda0d9c0498cebd9

In the Linux kernel, the following vulnerability has been resolved: i2c: virtio: fix completion handling The driver currently assumes that the notify callback is only received when the device is done with all the queued buffers. However, this is not true, since the notify callback could be called without any of the queued buffers being completed (for example, with virtio-pci and shared interrupts) or with only some of the buffers being completed (since the driver makes them available to the device in multiple separate virtqueue_add_sgs() calls). This can lead to incorrect data on the I2C bus or memory corruption in the guest if the device operates on buffers which are have been freed by the driver. (The WARN_ON in the driver is also triggered.) BUG kmalloc-128 (Tainted: G W ): Poison overwritten First byte 0x0 instead of 0x6b Allocated in i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28 memdup_user+0x2e/0xbd i2cdev_ioctl_rdwr+0x9d/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Freed in i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28 kfree+0x1bd/0x1cc i2cdev_ioctl_rdwr+0x1bb/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Fix this by calling virtio_get_buf() from the notify handler like other virtio drivers and by actually waiting for all the buffers to be completed.

MISC:https://git.kernel.org/stable/c/9cbb957441ed8873577d7d313a3d79d69f1dad5c | URL:https://git.kernel.org/stable/c/9cbb957441ed8873577d7d313a3d79d69f1dad5c | MISC:https://git.kernel.org/stable/c/b503de239f62eca898cfb7e820d9a35499137d22 | URL:https://git.kernel.org/stable/c/b503de239f62eca898cfb7e820d9a35499137d22

In the Linux kernel, the following vulnerability has been resolved: nfc: fix segfault in nfc_genl_dump_devices_done When kmalloc in nfc_genl_dump_devices() fails then nfc_genl_dump_devices_done() segfaults as below KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x26/0x80 Call Trace: <TASK> class_dev_iter_exit+0x15/0x20 nfc_genl_dump_devices_done+0x3b/0x50 genl_lock_done+0x84/0xd0 netlink_sock_destruct+0x8f/0x270 __sk_destruct+0x64/0x3b0 sk_destruct+0xa8/0xd0 __sk_free+0x2e8/0x3d0 sk_free+0x51/0x90 netlink_sock_destruct_work+0x1c/0x20 process_one_work+0x411/0x710 worker_thread+0x6fd/0xa80

MISC:https://git.kernel.org/stable/c/214af18abbe39db05beb305b2d11e87d09a6529c | URL:https://git.kernel.org/stable/c/214af18abbe39db05beb305b2d11e87d09a6529c | MISC:https://git.kernel.org/stable/c/2a8845b9603c545fddd17862282dc4c4ce0971e3 | URL:https://git.kernel.org/stable/c/2a8845b9603c545fddd17862282dc4c4ce0971e3 | MISC:https://git.kernel.org/stable/c/6644989642844de830f9b072cd65c553cb55946c | URL:https://git.kernel.org/stable/c/6644989642844de830f9b072cd65c553cb55946c | MISC:https://git.kernel.org/stable/c/c602863ad28ec86794cb4ab4edea5324f555f181 | URL:https://git.kernel.org/stable/c/c602863ad28ec86794cb4ab4edea5324f555f181 | MISC:https://git.kernel.org/stable/c/d731ecc6f2eaec68f4ad1542283bbc7d07bd0112 | URL:https://git.kernel.org/stable/c/d731ecc6f2eaec68f4ad1542283bbc7d07bd0112 | MISC:https://git.kernel.org/stable/c/d89e4211b51752daf063d638af50abed2fd5f96d | URL:https://git.kernel.org/stable/c/d89e4211b51752daf063d638af50abed2fd5f96d | MISC:https://git.kernel.org/stable/c/ea55b3797878752aa076b118afb727dcf79cac34 | URL:https://git.kernel.org/stable/c/ea55b3797878752aa076b118afb727dcf79cac34 | MISC:https://git.kernel.org/stable/c/fd79a0cbf0b2e34bcc45b13acf962e2032a82203 | URL:https://git.kernel.org/stable/c/fd79a0cbf0b2e34bcc45b13acf962e2032a82203