Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: tegra: Do not mark ACPI devices as irq safe<br /> <br /> On ACPI machines, the tegra i2c module encounters an issue due to a<br /> mutex being called inside a spinlock. This leads to the following bug:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585<br /> ...<br /> <br /> Call trace:<br /> __might_sleep<br /> __mutex_lock_common<br /> mutex_lock_nested<br /> acpi_subsys_runtime_resume<br /> rpm_resume<br /> tegra_i2c_xfer<br /> <br /> The problem arises because during __pm_runtime_resume(), the spinlock<br /> &amp;dev-&gt;power.lock is acquired before rpm_resume() is called. Later,<br /> rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on<br /> mutexes, triggering the error.<br /> <br /> To address this issue, devices on ACPI are now marked as not IRQ-safe,<br /> considering the dependency of acpi_subsys_runtime_resume() on mutexes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: cope with large MAX_SKB_FRAGS<br /> <br /> Sabrina reports that the igb driver does not cope well with large<br /> MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload<br /> corruption on TX.<br /> <br /> An easy reproducer is to run ssh to connect to the machine. With<br /> MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has<br /> been reported originally in<br /> https://bugzilla.redhat.com/show_bug.cgi?id=2265320<br /> <br /> The root cause of the issue is that the driver does not take into<br /> account properly the (possibly large) shared info size when selecting<br /> the ring layout, and will try to fit two packets inside the same 4K<br /> page even when the 1st fraglist will trump over the 2nd head.<br /> <br /> Address the issue by checking if 2K buffers are insufficient.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: cfg80211: Handle SSID based pmksa deletion<br /> <br /> wpa_supplicant 2.11 sends since 1efdba5fdc2c ("Handle PMKSA flush in the<br /> driver for SAE/OWE offload cases") SSID based PMKSA del commands.<br /> brcmfmac is not prepared and tries to dereference the NULL bssid and<br /> pmkid pointers in cfg80211_pmksa. PMKID_V3 operations support SSID based<br /> updates so copy the SSID.

Audition versions 24.4.1, 23.6.6 and earlier are affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

COMFAST CF-XR11 V2.7.2 has a command injection vulnerability in function sub_424CB4. Attackers can send POST request messages to /usr/bin/webmgnt and inject commands into parameter iface.

A stored cross-site scripting (XSS) vulnerability in the Discussion section of Perfex CRM v1.1.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Content parameter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: only decrement add_addr_accepted for MPJ req<br /> <br /> Adding the following warning ...<br /> <br /> WARN_ON_ONCE(msk-&gt;pm.add_addr_accepted == 0)<br /> <br /> ... before decrementing the add_addr_accepted counter helped to find a<br /> bug when running the "remove single subflow" subtest from the<br /> mptcp_join.sh selftest.<br /> <br /> Removing a &amp;#39;subflow&amp;#39; endpoint will first trigger a RM_ADDR, then the<br /> subflow closure. Before this patch, and upon the reception of the<br /> RM_ADDR, the other peer will then try to decrement this<br /> add_addr_accepted. That&amp;#39;s not correct because the attached subflows have<br /> not been created upon the reception of an ADD_ADDR.<br /> <br /> A way to solve that is to decrement the counter only if the attached<br /> subflow was an MP_JOIN to a remote id that was not 0, and initiated by<br /> the host receiving the RM_ADDR.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: only mark &amp;#39;subflow&amp;#39; endp as available<br /> <br /> Adding the following warning ...<br /> <br /> WARN_ON_ONCE(msk-&gt;pm.local_addr_used == 0)<br /> <br /> ... before decrementing the local_addr_used counter helped to find a bug<br /> when running the "remove single address" subtest from the mptcp_join.sh<br /> selftests.<br /> <br /> Removing a &amp;#39;signal&amp;#39; endpoint will trigger the removal of all subflows<br /> linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with<br /> rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used<br /> counter, which is wrong in this case because this counter is linked to<br /> &amp;#39;subflow&amp;#39; endpoints, and here it is a &amp;#39;signal&amp;#39; endpoint that is being<br /> removed.<br /> <br /> Now, the counter is decremented, only if the ID is being used outside<br /> of mptcp_pm_nl_rm_addr_or_subflow(), only for &amp;#39;subflow&amp;#39; endpoints, and<br /> if the ID is not 0 -- local_addr_used is not taking into account these<br /> ones. This marking of the ID as being available, and the decrement is<br /> done no matter if a subflow using this ID is currently available,<br /> because the subflow could have been closed before.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> char: xillybus: Check USB endpoints when probing device<br /> <br /> Ensure, as the driver probes the device, that all endpoints that the<br /> driver may attempt to access exist and are of the correct type.<br /> <br /> All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at<br /> address 1. This is verified in xillyusb_setup_base_eps().<br /> <br /> On top of that, a XillyUSB device may have additional Bulk OUT<br /> endpoints. The information about these endpoints&amp;#39; addresses is deduced<br /> from a data structure (the IDT) that the driver fetches from the device<br /> while probing it. These endpoints are checked in setup_channels().<br /> <br /> A XillyUSB device never has more than one IN endpoint, as all data<br /> towards the host is multiplexed in this single Bulk IN endpoint. This is<br /> why setup_channels() only checks OUT endpoints.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nouveau/firmware: use dma non-coherent allocator<br /> <br /> Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a<br /> BUG() on startup, when the iommu is enabled:<br /> <br /> kernel BUG at include/linux/scatterlist.h:187!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30<br /> Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019<br /> RIP: 0010:sg_init_one+0x85/0xa0<br /> Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54<br /> 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 0b 0f 0b<br /> 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00<br /> RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000<br /> RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508<br /> R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018<br /> FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0<br /> Call Trace:<br /> <br /> ? die+0x36/0x90<br /> ? do_trap+0xdd/0x100<br /> ? sg_init_one+0x85/0xa0<br /> ? do_error_trap+0x65/0x80<br /> ? sg_init_one+0x85/0xa0<br /> ? exc_invalid_op+0x50/0x70<br /> ? sg_init_one+0x85/0xa0<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? sg_init_one+0x85/0xa0<br /> nvkm_firmware_ctor+0x14a/0x250 [nouveau]<br /> nvkm_falcon_fw_ctor+0x42/0x70 [nouveau]<br /> ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau]<br /> r535_gsp_oneinit+0xb3/0x15f0 [nouveau]<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? nvkm_udevice_new+0x95/0x140 [nouveau]<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? ktime_get+0x47/0xb0<br /> <br /> Fix this by using the non-coherent allocator instead, I think there<br /> might be a better answer to this, but it involve ripping up some of<br /> APIs using sg lists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: move stopping keep-alive into nvme_uninit_ctrl()<br /> <br /> Commit 4733b65d82bd ("nvme: start keep-alive after admin queue setup")<br /> moves starting keep-alive from nvme_start_ctrl() into<br /> nvme_init_ctrl_finish(), but don&amp;#39;t move stopping keep-alive into<br /> nvme_uninit_ctrl(), so keep-alive work can be started and keep pending<br /> after failing to start controller, finally use-after-free is triggered if<br /> nvme host driver is unloaded.<br /> <br /> This patch fixes kernel panic when running nvme/004 in case that connection<br /> failure is triggered, by moving stopping keep-alive into nvme_uninit_ctrl().<br /> <br /> This way is reasonable because keep-alive is now started in<br /> nvme_init_ctrl_finish().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/boot: Avoid possible physmem_info segment corruption<br /> <br /> When physical memory for the kernel image is allocated it does not<br /> consider extra memory required for offsetting the image start to<br /> match it with the lower 20 bits of KASLR virtual base address. That<br /> might lead to kernel access beyond its memory range.