Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix remap of arena.<br /> <br /> The bpf arena logic didn&amp;#39;t account for mremap operation. Add a refcnt for<br /> multiple mmap events to prevent use-after-free in arena_vm_close.

Cross Site Scripting (XSS) vulnerability in AML Surety Eco up to 3.5 allows an attacker to run arbitrary code via crafted GET request using the id parameter.

Twisted is an event-based framework for internet applications, supporting Python 3.6+. The `twisted.web.util.redirectTo` function contains an HTML injection vulnerability. If application code allows an attacker to control the redirect URL this vulnerability may result in Reflected Cross-Site Scripting (XSS) in the redirect response HTML body. This vulnerability is fixed in 24.7.0rc1.

ImageMagick is a free and open-source software suite, used for editing and manipulating digital images. The `AppImage` version `ImageMagick` might use an empty path when setting `MAGICK_CONFIGURE_PATH` and `LD_LIBRARY_PATH` environment variables while executing, which might lead to arbitrary code execution by loading malicious configuration files or shared libraries in the current working directory while executing `ImageMagick`. The vulnerability is fixed in 7.11-36.

fast-xml-parser is an open source, pure javascript xml parser. a ReDOS exists on currency.js. This vulnerability is fixed in 4.4.1.

Note Mark is a web-based Markdown notes app. A stored cross-site scripting (XSS) vulnerability in Note Mark allows attackers to execute arbitrary web scripts via a crafted payload injected into the URL value of a link in the markdown content. This vulnerability is fixed in 0.13.1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: mcp251xfd: fix infinite loop when xmit fails<br /> <br /> When the mcp251xfd_start_xmit() function fails, the driver stops<br /> processing messages, and the interrupt routine does not return,<br /> running indefinitely even after killing the running application.<br /> <br /> Error messages:<br /> [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16<br /> [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).<br /> ... and repeat forever.<br /> <br /> The issue can be triggered when multiple devices share the same SPI<br /> interface. And there is concurrent access to the bus.<br /> <br /> The problem occurs because tx_ring-&gt;head increments even if<br /> mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX<br /> package while still expecting a response in<br /> mcp251xfd_handle_tefif_one().<br /> <br /> Resolve the issue by starting a workqueue to write the tx obj<br /> synchronously if err = -EBUSY. In case of another error, decrement<br /> tx_ring-&gt;head, remove skb from the echo stack, and drop the message.<br /> <br /> [mkl: use more imperative wording in patch description]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes<br /> <br /> In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is<br /> assigned to mode, which will lead to a possible NULL pointer dereference<br /> on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().<br /> Add a check to avoid null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: avoid using null object of framebuffer<br /> <br /> Instead of using state-&gt;fb-&gt;obj[0] directly, get object from framebuffer<br /> by calling drm_gem_fb_get_obj() and return error code when object is<br /> null to avoid using null object of framebuffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/fbdev-dma: Only set smem_start is enable per module option<br /> <br /> Only export struct fb_info.fix.smem_start if that is required by the<br /> user and the memory does not come from vmalloc().<br /> <br /> Setting struct fb_info.fix.smem_start breaks systems where DMA<br /> memory is backed by vmalloc address space. An example error is<br /> shown below.<br /> <br /> [ 3.536043] ------------[ cut here ]------------<br /> [ 3.540716] virt_to_phys used for non-linear address: 000000007fc4f540 (0xffff800086001000)<br /> [ 3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98<br /> [ 3.565455] Modules linked in:<br /> [ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 6.6.23-06226-g4986cc3e1b75-dirty #250<br /> [ 3.577310] Hardware name: NXP i.MX95 19X19 board (DT)<br /> [ 3.582452] Workqueue: events_unbound deferred_probe_work_func<br /> [ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 3.595233] pc : __virt_to_phys+0x68/0x98<br /> [ 3.599246] lr : __virt_to_phys+0x68/0x98<br /> [ 3.603276] sp : ffff800083603990<br /> [ 3.677939] Call trace:<br /> [ 3.680393] __virt_to_phys+0x68/0x98<br /> [ 3.684067] drm_fbdev_dma_helper_fb_probe+0x138/0x238<br /> [ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0<br /> [ 3.695385] drm_fb_helper_initial_config+0x4c/0x68<br /> [ 3.700264] drm_fbdev_dma_client_hotplug+0x8c/0xe0<br /> [ 3.705161] drm_client_register+0x60/0xb0<br /> [ 3.709269] drm_fbdev_dma_setup+0x94/0x148<br /> <br /> Additionally, DMA memory is assumed to by contiguous in physical<br /> address space, which is not guaranteed by vmalloc().<br /> <br /> Resolve this by checking the module flag drm_leak_fbdev_smem when<br /> DRM allocated the instance of struct fb_info. Fbdev-dma then only<br /> sets smem_start only if required (via FBINFO_HIDE_SMEM_START). Also<br /> guarantee that the framebuffer is not located in vmalloc address<br /> space.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes<br /> <br /> In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is<br /> assigned to mode, which will lead to a possible NULL pointer dereference<br /> on failure of drm_mode_duplicate(). Add a check to avoid npd.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: atm: cxacru: fix endpoint checking in cxacru_bind()<br /> <br /> Syzbot is still reporting quite an old issue [1] that occurs due to<br /> incomplete checking of present usb endpoints. As such, wrong<br /> endpoints types may be used at urb sumbitting stage which in turn<br /> triggers a warning in usb_submit_urb().<br /> <br /> Fix the issue by verifying that required endpoint types are present<br /> for both in and out endpoints, taking into account cmd endpoint type.<br /> <br /> Unfortunately, this patch has not been tested on real hardware.<br /> <br /> [1] Syzbot report:<br /> usb 1-1: BOGUS urb xfer, pipe 1 != type 3<br /> WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502<br /> Modules linked in:<br /> CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502<br /> ...<br /> Call Trace:<br /> cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649<br /> cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760<br /> cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209<br /> usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055<br /> cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363<br /> usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396<br /> call_driver_probe drivers/base/dd.c:517 [inline]<br /> really_probe+0x23c/0xcd0 drivers/base/dd.c:595<br /> __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747<br /> driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777<br /> __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894<br /> bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427<br /> __device_attach+0x228/0x4a0 drivers/base/dd.c:965<br /> bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487<br /> device_add+0xc2f/0x2180 drivers/base/core.c:3354<br /> usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170<br /> usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238<br /> usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293