Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: Shuffle the tx ring before enabling tx<br /> <br /> Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board,<br /> the rootfs may take an extended time to recover after a suspend.<br /> Upon investigation, it was determined that the issue originates from a<br /> problem in the macb driver.<br /> <br /> According to the Zynq UltraScale TRM [1], when transmit is disabled,<br /> the transmit buffer queue pointer resets to point to the address<br /> specified by the transmit buffer queue base address register.<br /> <br /> In the current implementation, the code merely resets `queue-&gt;tx_head`<br /> and `queue-&gt;tx_tail` to &amp;#39;0&amp;#39;. This approach presents several issues:<br /> <br /> - Packets already queued in the tx ring are silently lost,<br /> leading to memory leaks since the associated skbs cannot be released.<br /> <br /> - Concurrent write access to `queue-&gt;tx_head` and `queue-&gt;tx_tail` may<br /> occur from `macb_tx_poll()` or `macb_start_xmit()` when these values<br /> are reset to &amp;#39;0&amp;#39;.<br /> <br /> - The transmission may become stuck on a packet that has already been sent<br /> out, with its &amp;#39;TX_USED&amp;#39; bit set, but has not yet been processed. However,<br /> due to the manipulation of &amp;#39;queue-&gt;tx_head&amp;#39; and &amp;#39;queue-&gt;tx_tail&amp;#39;,<br /> `macb_tx_poll()` incorrectly assumes there are no packets to handle<br /> because `queue-&gt;tx_head == queue-&gt;tx_tail`. This issue is only resolved<br /> when a new packet is placed at this position. This is the root cause of<br /> the prolonged recovery time observed for the NFS root filesystem.<br /> <br /> To resolve this issue, shuffle the tx ring and tx skb array so that<br /> the first unsent packet is positioned at the start of the tx ring.<br /> Additionally, ensure that updates to `queue-&gt;tx_head` and<br /> `queue-&gt;tx_tail` are properly protected with the appropriate lock.<br /> <br /> [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix use-after-free race in VM acquire<br /> <br /> Replace non-atomic vm-&gt;process_info assignment with cmpxchg()<br /> to prevent race when parent/child processes sharing a drm_file<br /> both try to acquire the same VM after fork().<br /> <br /> (cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Fix NULL pointer dereference in device cleanup<br /> <br /> When GPU initialization fails due to an unsupported HW block<br /> IP blocks may have a NULL version pointer. During cleanup in<br /> amdgpu_device_fini_hw, the code calls amdgpu_device_set_pg_state and<br /> amdgpu_device_set_cg_state which iterate over all IP blocks and access<br /> adev-&gt;ip_blocks[i].version without NULL checks, leading to a kernel<br /> NULL pointer dereference.<br /> <br /> Add NULL checks for adev-&gt;ip_blocks[i].version in both<br /> amdgpu_device_set_cg_state and amdgpu_device_set_pg_state to prevent<br /> dereferencing NULL pointers during GPU teardown when initialization has<br /> failed.<br /> <br /> (cherry picked from commit b7ac77468cda92eecae560b05f62f997a12fe2f2)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix potential overflow of shmem scatterlist length<br /> <br /> When a scatterlists table of a GEM shmem object of size 4 GB or more is<br /> populated with pages allocated from a folio, unsigned int .length<br /> attribute of a scatterlist may get overflowed if total byte length of<br /> pages allocated to that single scatterlist happens to reach or cross the<br /> 4GB limit. As a consequence, users of the object may suffer from hitting<br /> unexpected, premature end of the object&amp;#39;s backing pages.<br /> <br /> [278.780187] ------------[ cut here ]------------<br /> [278.780377] WARNING: CPU: 1 PID: 2326 at drivers/gpu/drm/i915/i915_mm.c:55 remap_sg+0x199/0x1d0 [i915]<br /> ...<br /> [278.780654] CPU: 1 UID: 0 PID: 2326 Comm: gem_mmap_offset Tainted: G S U 6.17.0-rc1-CI_DRM_16981-ged823aaa0607+ #1 PREEMPT(voluntary)<br /> [278.780656] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER<br /> [278.780658] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024<br /> [278.780659] RIP: 0010:remap_sg+0x199/0x1d0 [i915]<br /> ...<br /> [278.780786] Call Trace:<br /> [278.780787] <br /> [278.780788] ? __apply_to_page_range+0x3e6/0x910<br /> [278.780795] ? __pfx_remap_sg+0x10/0x10 [i915]<br /> [278.780906] apply_to_page_range+0x14/0x30<br /> [278.780908] remap_io_sg+0x14d/0x260 [i915]<br /> [278.781013] vm_fault_cpu+0xd2/0x330 [i915]<br /> [278.781137] __do_fault+0x3a/0x1b0<br /> [278.781140] do_fault+0x322/0x640<br /> [278.781143] __handle_mm_fault+0x938/0xfd0<br /> [278.781150] handle_mm_fault+0x12c/0x300<br /> [278.781152] ? lock_mm_and_find_vma+0x4b/0x760<br /> [278.781155] do_user_addr_fault+0x2d6/0x8e0<br /> [278.781160] exc_page_fault+0x96/0x2c0<br /> [278.781165] asm_exc_page_fault+0x27/0x30<br /> ...<br /> <br /> That issue was apprehended by the author of a change that introduced it,<br /> and potential risk even annotated with a comment, but then never addressed.<br /> <br /> When adding folio pages to a scatterlist table, take care of byte length<br /> of any single scatterlist not exceeding max_segment.<br /> <br /> (cherry picked from commit 06249b4e691a75694c014a61708c007fb5755f60)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Fix a few more NULL pointer dereference in device cleanup<br /> <br /> I found a few more paths that cleanup fails due to a NULL version pointer<br /> on unsupported hardware.<br /> <br /> Add NULL checks as applicable.<br /> <br /> (cherry picked from commit f5a05f8414fc10f307eb965f303580c7778f8dd2)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix in-place encryption corruption in SMB2_write()<br /> <br /> SMB2_write() places write payload in iov[1..n] as part of rq_iov.<br /> smb3_init_transform_rq() pointer-shares rq_iov, so crypt_message()<br /> encrypts iov[1] in-place, replacing the original plaintext with<br /> ciphertext. On a replayable error, the retry sends the same iov[1]<br /> which now contains ciphertext instead of the original data,<br /> resulting in corruption.<br /> <br /> The corruption is most likely to be observed when connections are<br /> unstable, as reconnects trigger write retries that re-send the<br /> already-encrypted data.<br /> <br /> This affects SFU mknod, MF symlinks, etc. On kernels before<br /> 6.10 (prior to the netfs conversion), sync writes also used<br /> this path and were similarly affected. The async write path<br /> wasn&amp;#39;t unaffected as it uses rq_iter which gets deep-copied.<br /> <br /> Fix by moving the write payload into rq_iter via iov_iter_kvec(),<br /> so smb3_init_transform_rq() deep-copies it before encryption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/apic: Disable x2apic on resume if the kernel expects so<br /> <br /> When resuming from s2ram, firmware may re-enable x2apic mode, which may have<br /> been disabled by the kernel during boot either because it doesn&amp;#39;t support IRQ<br /> remapping or for other reasons. This causes the kernel to continue using the<br /> xapic interface, while the hardware is in x2apic mode, which causes hangs.<br /> This happens on defconfig + bare metal + s2ram.<br /> <br /> Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be<br /> disabled, i.e. when x2apic_mode = 0.<br /> <br /> The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the<br /> pre-sleep configuration or initial boot configuration for each CPU, including<br /> MSR state:<br /> <br /> When executing from the power-on reset vector as a result of waking from an<br /> S2 or S3 sleep state, the platform firmware performs only the hardware<br /> initialization required to restore the system to either the state the<br /> platform was in prior to the initial operating system boot, or to the<br /> pre-sleep configuration state. In multiprocessor systems, non-boot<br /> processors should be placed in the same state as prior to the initial<br /> operating system boot.<br /> <br /> (further ahead)<br /> <br /> If this is an S2 or S3 wake, then the platform runtime firmware restores<br /> minimum context of the system before jumping to the waking vector. This<br /> includes:<br /> <br /> CPU configuration. Platform runtime firmware restores the pre-sleep<br /> configuration or initial boot configuration of each CPU (MSR, MTRR,<br /> firmware update, SMBase, and so on). Interrupts must be disabled (for<br /> IA-32 processors, disabled by CLI instruction).<br /> <br /> (and other things)<br /> <br /> So at least as per the spec, re-enablement of x2apic by the firmware is<br /> allowed if "x2apic on" is a part of the initial boot configuration.<br /> <br /> [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization<br /> <br /> [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fix NULL pointer dereference in ublk_ctrl_set_size()<br /> <br /> ublk_ctrl_set_size() unconditionally dereferences ub-&gt;ub_disk via<br /> set_capacity_and_notify() without checking if it is NULL.<br /> <br /> ub-&gt;ub_disk is NULL before UBLK_CMD_START_DEV completes (it is only<br /> assigned in ublk_ctrl_start_dev()) and after UBLK_CMD_STOP_DEV runs<br /> (ublk_detach_disk() sets it to NULL). Since the UBLK_CMD_UPDATE_SIZE<br /> handler performs no state validation, a user can trigger a NULL pointer<br /> dereference by sending UPDATE_SIZE to a device that has been added but<br /> not yet started, or one that has been stopped.<br /> <br /> Fix this by checking ub-&gt;ub_disk under ub-&gt;mutex before dereferencing<br /> it, and returning -ENODEV if the disk is not available.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix undersized l_iclog_roundoff values<br /> <br /> If the superblock doesn&amp;#39;t list a log stripe unit, we set the incore log<br /> roundoff value to 512. This leads to corrupt logs and unmountable<br /> filesystems in generic/617 on a disk with 4k physical sectors...<br /> <br /> XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c<br /> XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197.<br /> XFS (sda1): failed to locate log tail<br /> XFS (sda1): log mount/recovery failed: error -74<br /> XFS (sda1): log mount failed<br /> XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c<br /> XFS (sda1): Ending clean mount<br /> <br /> ...on the current xfsprogs for-next which has a broken mkfs. xfs_info<br /> shows this...<br /> <br /> meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks<br /> = sectsz=4096 attr=2, projid32bit=1<br /> = crc=1 finobt=1, sparse=1, rmapbt=1<br /> = reflink=1 bigtime=1 inobtcount=1 nrext64=1<br /> = exchange=1 metadir=1<br /> data = bsize=4096 blocks=2579968, imaxpct=25<br /> = sunit=0 swidth=0 blks<br /> naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1<br /> log =internal log bsize=4096 blocks=16384, version=2<br /> = sectsz=4096 sunit=0 blks, lazy-count=1<br /> realtime =none extsz=4096 blocks=0, rtextents=0<br /> = rgcount=0 rgsize=268435456 extents<br /> = zoned=0 start=0 reserved=0<br /> <br /> ...observe that the log section has sectsz=4096 sunit=0, which means<br /> that the roundoff factor is 512, not 4096 as you&amp;#39;d expect. We should<br /> fix mkfs not to generate broken filesystems, but anyone can fuzz the<br /> ondisk superblock so we should be more cautious. I think the inadequate<br /> logic predates commit a6a65fef5ef8d0, but that&amp;#39;s clearly going to<br /> require a different backport.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/kbuf: check if target buffer list is still legacy on recycle<br /> <br /> There&amp;#39;s a gap between when the buffer was grabbed and when it<br /> potentially gets recycled, where if the list is empty, someone could&amp;#39;ve<br /> upgraded it to a ring provided type. This can happen if the request<br /> is forced via io-wq. The legacy recycling is missing checking if the<br /> buffer_list still exists, and if it&amp;#39;s of the correct type. Add those<br /> checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix transaction abort when snapshotting received subvolumes<br /> <br /> Currently a user can trigger a transaction abort by snapshotting a<br /> previously received snapshot a bunch of times until we reach a<br /> BTRFS_UUID_KEY_RECEIVED_SUBVOL item overflow (the maximum item size we<br /> can store in a leaf). This is very likely not common in practice, but<br /> if it happens, it turns the filesystem into RO mode. The snapshot, send<br /> and set_received_subvol and subvol_setflags (used by receive) don&amp;#39;t<br /> require CAP_SYS_ADMIN, just inode_owner_or_capable(). A malicious user<br /> could use this to turn a filesystem into RO mode and disrupt a system.<br /> <br /> Reproducer script:<br /> <br /> $ cat test.sh<br /> #!/bin/bash<br /> <br /> DEV=/dev/sdi<br /> MNT=/mnt/sdi<br /> <br /> # Use smallest node size to make the test faster.<br /> mkfs.btrfs -f --nodesize 4K $DEV<br /> mount $DEV $MNT<br /> <br /> # Create a subvolume and set it to RO so that it can be used for send.<br /> btrfs subvolume create $MNT/sv<br /> touch $MNT/sv/foo<br /> btrfs property set $MNT/sv ro true<br /> <br /> # Send and receive the subvolume into snaps/sv.<br /> mkdir $MNT/snaps<br /> btrfs send $MNT/sv | btrfs receive $MNT/snaps<br /> <br /> # Now snapshot the received subvolume, which has a received_uuid, a<br /> # lot of times to trigger the leaf overflow.<br /> total=500<br /> for ((i = 1; i /dev/null<br /> done<br /> echo<br /> <br /> umount $MNT<br /> <br /> When running the test:<br /> <br /> $ ./test.sh<br /> (...)<br /> Create subvolume &amp;#39;/mnt/sdi/sv&amp;#39;<br /> At subvol /mnt/sdi/sv<br /> At subvol sv<br /> Creating snapshot 496/500ERROR: Could not create subvolume: Value too large for defined data type<br /> Creating snapshot 497/500ERROR: Could not create subvolume: Read-only file system<br /> Creating snapshot 498/500ERROR: Could not create subvolume: Read-only file system<br /> Creating snapshot 499/500ERROR: Could not create subvolume: Read-only file system<br /> Creating snapshot 500/500ERROR: Could not create subvolume: Read-only file system<br /> <br /> And in dmesg/syslog:<br /> <br /> $ dmesg<br /> (...)<br /> [251067.627338] BTRFS warning (device sdi): insert uuid item failed -75 (0x4628b21c4ac8d898, 0x2598bee2b1515c91) type 252!<br /> [251067.629212] ------------[ cut here ]------------<br /> [251067.630033] BTRFS: Transaction aborted (error -75)<br /> [251067.630871] WARNING: fs/btrfs/transaction.c:1907 at create_pending_snapshot.cold+0x52/0x465 [btrfs], CPU#10: btrfs/615235<br /> [251067.632851] Modules linked in: btrfs dm_zero (...)<br /> [251067.644071] CPU: 10 UID: 0 PID: 615235 Comm: btrfs Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full)<br /> [251067.646165] Tainted: [W]=WARN<br /> [251067.646733] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [251067.648735] RIP: 0010:create_pending_snapshot.cold+0x55/0x465 [btrfs]<br /> [251067.649984] Code: f0 48 0f (...)<br /> [251067.653313] RSP: 0018:ffffce644908fae8 EFLAGS: 00010292<br /> [251067.653987] RAX: 00000000ffffff01 RBX: ffff8e5639e63a80 RCX: 00000000ffffffd3<br /> [251067.655042] RDX: ffff8e53faa76b00 RSI: 00000000ffffffb5 RDI: ffffffffc0919750<br /> [251067.656077] RBP: ffffce644908fbd8 R08: 0000000000000000 R09: ffffce644908f820<br /> [251067.657068] R10: ffff8e5adc1fffa8 R11: 0000000000000003 R12: ffff8e53c0431bd0<br /> [251067.658050] R13: ffff8e5414593600 R14: ffff8e55efafd000 R15: 00000000ffffffb5<br /> [251067.659019] FS: 00007f2a4944b3c0(0000) GS:ffff8e5b27dae000(0000) knlGS:0000000000000000<br /> [251067.660115] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [251067.660943] CR2: 00007ffc5aa57898 CR3: 00000005813a2003 CR4: 0000000000370ef0<br /> [251067.661972] Call Trace:<br /> [251067.662292] <br /> [251067.662653] create_pending_snapshots+0x97/0xc0 [btrfs]<br /> [251067.663413] btrfs_commit_transaction+0x26e/0xc00 [btrfs]<br /> [251067.664257] ? btrfs_qgroup_convert_reserved_meta+0x35/0x390 [btrfs]<br /> [251067.665238] ? _raw_spin_unlock+0x15/0x30<br /> [251067.665837] ? record_root_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix transaction abort on file creation due to name hash collision<br /> <br /> If we attempt to create several files with names that result in the same<br /> hash, we have to pack them in same dir item and that has a limit inherent<br /> to the leaf size. However if we reach that limit, we trigger a transaction<br /> abort and turns the filesystem into RO mode. This allows for a malicious<br /> user to disrupt a system, without the need to have administration<br /> privileges/capabilities.<br /> <br /> Reproducer:<br /> <br /> $ cat exploit-hash-collisions.sh<br /> #!/bin/bash<br /> <br /> DEV=/dev/sdi<br /> MNT=/mnt/sdi<br /> <br /> # Use smallest node size to make the test faster and require fewer file<br /> # names that result in hash collision.<br /> mkfs.btrfs -f --nodesize 4K $DEV<br /> mount $DEV $MNT<br /> <br /> # List of names that result in the same crc32c hash for btrfs.<br /> declare -a names=(<br /> &amp;#39;foobar&amp;#39;<br /> &amp;#39;%a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6jZnkDtUUru1t@RouaUe_L:@xGkbO3nCwvLNYeK9vhE628gss:T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC&amp;#39;<br /> &amp;#39;AQci3EUB%shMsg-N%frgU:02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB:=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmqrMiL9-Y0I_l5Fnam04CGIg=8@U:Z&amp;#39;<br /> &amp;#39;CvVqJpJzueKcuA$wqwePfyu7VxuWNN3ho$p0zi2H8QFYK$7YlEqOhhb%:hHgjhIjW5vnqWHKNP4&amp;#39;<br /> &amp;#39;ET:vk@rFU4tsvMB0$C_p=xQHaYZjvoF%-BTc%wkFW8yaDAPcCYoR%x$FH5O:&amp;#39;<br /> &amp;#39;HwTon%v7SGSP4FE08jBwwiu5aot2CFKXHTeEAa@38fUcNGOWvE@Mz6WBeDH_VooaZ6AgsXPkVGwy9l@@ZbNXabUU9csiWrrOp0MWUdfi$EZ3w9GkIqtz7I_eOsByOkBOO&amp;#39;<br /> &amp;#39;Ij%2VlFGXSuPvxJGf5UWy6O@1svxGha%b@=%wjkq:CIgE6u7eJOjmQY5qTtxE2Rjbis9@us&amp;#39;<br /> &amp;#39;KBkjG5%9R8K9sOG8UTnAYjxLNAvBmvV5vz3IiZaPmKuLYO03-6asI9lJ_j4@6Xo$KZicaLWJ3Pv8XEwVeUPMwbHYWwbx0pYvNlGMO9F:ZhHAwyctnGy%_eujl%WPd4U2BI7qooOSr85J-C2V$LfY&amp;#39;<br /> &amp;#39;NcRfDfuUQ2=zP8K3CCF5dFcpfiOm6mwenShsAb_F%n6GAGC7fT2JFFn:c35X-3aYwoq7jNX5$ZJ6hI3wnZs$7KgGi7wjulffhHNUxAT0fRRLF39vJ@NvaEMxsMO&amp;#39;<br /> &amp;#39;Oj42AQAEzRoTxa5OuSKIr=A_lwGMy132v4g3Pdq1GvUG9874YseIFQ6QU&amp;#39;<br /> &amp;#39;Ono7avN5GjC:_6dBJ_&amp;#39;<br /> &amp;#39;WHmN2gnmaN-9dVDy4aWo:yNGFzz8qsJyJhWEWcud7$QzN2D9R0efIWWEdu5kwWr73NZm4=@CoCDxrrZnRITr-kGtU_cfW2:%2_am&amp;#39;<br /> &amp;#39;WiFnuTEhAG9FEC6zopQmj-A-$LDQ0T3WULz%ox3UZAPybSV6v1Z$b4L_XBi4M4BMBtJZpz93r9xafpB77r:lbwvitWRyo$odnAUYlYMmU4RvgnNd--e=I5hiEjGLETTtaScWlQp8mYsBovZwM2k&amp;#39;<br /> &amp;#39;XKyH=OsOAF3p%uziGF_ZVr$ivrvhVgD@1u%5RtrV-gl_vqAwHkK@x7YwlxX3qT6WKKQ%PR56NrUBU2dOAOAdzr2=5nJuKPM-T-$ZpQfCL7phxQbUcb:BZOTPaFExc-qK-gDRCDW2&amp;#39;<br /> &amp;#39;d3uUR6OFEwZr%ns1XH_@tbxA@cCPmbBRLdyh7p6V45H$P2$F%w0RqrD3M0g8aGvWpoTFMiBdOTJXjD:JF7=h9a_43xBywYAP%r$SPZi%zDg%ql-KvkdUCtF9OLaQlxmd&amp;#39;<br /> &amp;#39;ePTpbnit%hyNm@WELlpKzNZYOzOTf8EQ$sEfkMy1VOfIUu3coyvIr13-Y7Sv5v-Ivax2Go_GQRFMU1b3362nktT9WOJf3SpT%z8sZmM3gvYQBDgmKI%%RM-G7hyrhgYflOw%z::ZRcv5O:lDCFm&amp;#39;<br /> &amp;#39;evqk743Y@dvZAiG5J05L_ROFV@$2%rVWJ2%3nxV72-W7$e$-SK3tuSHA2mBt$qloC5jwNx33GmQUjD%akhBPu=VJ5g$xhlZiaFtTrjeeM5x7dt4cHpX0cZkmfImndYzGmvwQG:$euFYmXn$_2rA9mKZ&amp;#39;<br /> &amp;#39;gkgUtnihWXsZQTEkrMAWIxir09k3t7jk_IK25t1:cy1XWN0GGqC%FrySdcmU7M8MuPO_ppkLw3=Dfr0UuBAL4%GFk2$Ma10V1jDRGJje%Xx9EV2ERaWKtjpwiZwh0gCSJsj5UL7CR8RtW5opCVFKGGy8Cky&amp;#39;<br /> &amp;#39;hNgsG_8lNRik3PvphqPm0yEH3P%%fYG:kQLY=6O-61Wa6nrV_WVGR6TLB09vHOv%g4VQRP8Gzx7VXUY1qvZyS&amp;#39;<br /> &amp;#39;isA7JVzN12xCxVPJZ_qoLm-pTBuhjjHMvV7o=F:EaClfYNyFGlsfw-Kf%uxdqW-kwk1sPl2vhbjyHU1A6$hz&amp;#39;<br /> &amp;#39;kiJ_fgcdZFDiOptjgH5PN9-PSyLO4fbk_:u5_2tz35lV_iXiJ6cx7pwjTtKy-XGaQ5IefmpJ4N_ZqGsqCsKuqOOBgf9LkUdffHet@Wu&amp;#39;<br /> &amp;#39;lvwtxyhE9:%Q3UxeHiViUyNzJsy:fm38pg_b6s25JvdhOAT=1s0$pG25x=LZ2rlHTszj=gN6M4zHZYr_qrB49i=pA--@WqWLIuX7o1S_SfS@2FSiUZN&amp;#39;<br /> &amp;#39;rC24cw3UBDZ=5qJBUMs9e$=S4Y94ni%Z8639vnrGp=0Hv4z3dNFL0fBLmQ40=EYIY:Z=SLc@QLMSt2zsss2ZXrP7j4=&amp;#39;<br /> &amp;#39;uwGl2s-fFrf@GqS=DQqq2I0LJSsOmM%xzTjS:lzXguE3wChdMoHYtLRKPvfaPOZF2fER@j53evbKa7R%A7r4%YEkD=kicJe@SFiGtXHbKe4gCgPAYbnVn&amp;#39;<br /> &amp;#39;UG37U6KKua2bgc:IHzRs7BnB6FD:2Mt5Cc5NdlsW%$1tyvnfz7S27FvNkroXwAW:mBZLA1@qa9WnDbHCDmQmfPMC9z-Eq6QT0jhhPpqyymaD:R02ghwYo%yx7SAaaq-:x33LYpei$5g8DMl3C&amp;#39;<br /> &amp;#39;y2vjek0FE1PDJC0qpfnN:x8k2wCFZ9xiUF2ege=JnP98R%wxjKkdfEiLWvQzmnW&amp;#39;<br /> &amp;#39;8-HCSgH5B%K7P8_jaVtQhBXpBk:pE-$P7ts58U0J@iR9YZntMPl7j$s62yAJO@_9eanFPS54b=UTw$94C-t=HLxT8n6o9P=QnIxq-f1=Ne2dvhe6WbjEQtc&amp;#39;<br /> &amp;#39;YPPh:IFt2mtR6XWSmjHptXL_hbSYu8bMw-JP8@PNyaFkdNFsk$M=xfL6LDKCDM-mSyGA_2MBwZ8Dr4=R1D%7-mC<br /> ---truncated---