In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel-vbtn: Protect ACPI notify handler against recursion Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") ACPI notify handlers like the intel-vbtn notify_handler() may run on multiple CPU cores racing with themselves. This race gets hit on Dell Venue 7140 tablets when undocking from the keyboard, causing the handler to try and register priv->switches_dev twice, as can be seen from the dev_info() message getting logged twice: [ 83.861800] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event [ 83.861858] input: Intel Virtual Switches as /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17 [ 83.861865] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event After which things go seriously wrong: [ 83.861872] sysfs: cannot create duplicate filename '/devices/pci00…

The req package before 3.43.4 for Go may send an unintended request when a malformed URL is provided, because cleanHost in http.go intentionally uses a "garbage in, garbage out" design.

A vulnerability classified as critical has been found in Go-Tribe gotribe up to cd3ccd32cd77852c9ea73f986eaf8c301cfb6310. Affected is the function Sign of the file pkg/token/token.go. The manipulation of the argument config.key leads to hard-coded credentials. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. The patch is identified as 4fb9b9e80a2beedd09d9fde4b9cf5bd510baf18f. It is recommended to apply a patch to fix this issue.

A vulnerability was found in Go-Tribe gotribe-admin 1.0 and classified as problematic. Affected by this issue is the function InitRoutes of the file internal/app/routes/routes.go of the component Log Handler. The manipulation leads to deserialization. The patch is identified as 45ac90d6d1f82716f77dbcdf8e7309c229080e3c. It is recommended to apply a patch to fix this issue.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter() In rtw89_sta_info_get_iter() 'status->he_gi' is compared to array size. But then 'rate->he_gi' is used as array index instead of 'status->he_gi'. This can lead to go beyond array boundaries in case of 'rate->he_gi' is not equal to 'status->he_gi' and is bigger than array size. Looks like "copy-paste" mistake. Fix this mistake by replacing 'rate->he_gi' with 'status->he_gi'. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Tenda FH1206 v02.03.01.35 was discovered to contain a stack overflow via the Go parameter in the fromSafeUrlFilter function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted POST request.

Tenda FH1201 v1.2.0.14 (408) was discovered to contain a stack overflow via the Go parameter in the fromSafeClientFilter function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted POST request.

In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix NULL pointer dereference in gfs2_log_flush In gfs2_jindex_free(), set sdp->sd_jdesc to NULL under the log flush lock to provide exclusion against gfs2_log_flush(). In gfs2_log_flush(), check if sdp->sd_jdesc is non-NULL before dereferencing it. Otherwise, we could run into a NULL pointer dereference when outstanding glock work races with an unmount (glock_work_func -> run_queue -> do_xmote -> inode_go_sync -> gfs2_log_flush).

In the Linux kernel, the following vulnerability has been resolved: btrfs: scrub: handle RST lookup error correctly [BUG] When running btrfs/060 with forced RST feature, it would crash the following ASSERT() inside scrub_read_endio(): ASSERT(sector_nr < stripe->nr_sectors); Before that, we would have tree dump from btrfs_get_raid_extent_offset(), as we failed to find the RST entry for the range. [CAUSE] Inside scrub_submit_extent_sector_read() every time we allocated a new bbio we immediately called btrfs_map_block() to make sure there was some RST range covering the scrub target. But if btrfs_map_block() fails, we immediately call endio for the bbio, while the bbio is newly allocated, it's completely empty. Then inside scrub_read_endio(), we go through the bvecs to find the sector number (as bi_sector is no longer reliable if the bio is submitted to lower layers). And since the bio is empty, such bvecs iteration would not find any sector matching the sector, and return secto…

go-chart v2.1.1 was discovered to contain an infinite loop via the drawCanvas() function.