CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48870 – tty: fix possible null-ptr-defer in spk_ttyio_release
https://notcve.org/view.php?id=CVE-2022-48870
In the Linux kernel, the following vulnerability has been resolved: tty: fix possible null-ptr-defer in spk_ttyio_release Run the following tests on the qemu platform: syzkaller:~# modprobe speakup_audptr input: Speakup as /devices/virtual/input/input4 initialized device: /dev/synth, node (MAJOR 10, MINOR 125) speakup 3.1.6: initialized synth name on entry is: (null) synth probe spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned failed (errno -16), then remove the module, we will get a null-ptr-defer problem, as follow: syzkaller:~# modprobe -r speakup_audptr releasing synth audptr BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1 RIP: 0010:mutex_lock+0x14/0x30 Call Trace: <TASK> spk_ttyio_release+0x19/0x70 [speakup] synth_release.part.6+0xac/0xc0 [speakup] synth_remove+0x56/0x60 [speakup] __x64_sys_delete_module+0x156/0x250 ? fpregs_assert_state_consistent+0x1d/0x50 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Modules linked in: speakup_audptr(-) speakup Dumping ftrace buffer: in_synth->dev was not initialized during modprobe, so we add check for in_synth->dev to fix this bug. • https://git.kernel.org/stable/c/4f2a81f3a88217e7340b2cab5c0a5ebd0112514c https://git.kernel.org/stable/c/2da67bff29ab49caafb0766e8b8383b735ff796f https://git.kernel.org/stable/c/64152e05a4de3ebf59f1740a0985a6d5fba0c77b https://git.kernel.org/stable/c/5abbeebd8296c2301023b8dc4b5a6c0d5229b4f5 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48869 – USB: gadgetfs: Fix race between mounting and unmounting
https://notcve.org/view.php?id=CVE-2022-48869
In the Linux kernel, the following vulnerability has been resolved: USB: gadgetfs: Fix race between mounting and unmounting The syzbot fuzzer and Gerald Lee have identified a use-after-free bug in the gadgetfs driver, involving processes concurrently mounting and unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super() can race with gadgetfs_kill_sb(), causing the latter to deallocate the_device while the former is using it. The output from KASAN says, in part: BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline] BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline] BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline] BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline] BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline] BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline] BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689 CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> ... atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline] __refcount_sub_and_test include/linux/refcount.h:272 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] put_dev drivers/usb/gadget/legacy/inode.c:159 [inline] gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 vfs_get_super fs/super.c:1190 [inline] get_tree_single+0xd0/0x160 fs/super.c:1207 vfs_get_tree+0x88/0x270 fs/super.c:1531 vfs_fsconfig_locked fs/fsopen.c:232 [inline] The simplest solution is to ensure that gadgetfs_fill_super() and gadgetfs_kill_sb() are serialized by making them both acquire a new mutex. • https://git.kernel.org/stable/c/e5d82a7360d124ae1a38c2a5eac92ba49b125191 https://git.kernel.org/stable/c/9a39f4626b361ee7aa10fd990401c37ec3b466ae https://git.kernel.org/stable/c/856e4b5e53f21edbd15d275dde62228dd94fb2b4 https://git.kernel.org/stable/c/a2e075f40122d8daf587db126c562a67abd69cf9 https://git.kernel.org/stable/c/616fd34d017000ecf9097368b13d8a266f4920b3 https://git.kernel.org/stable/c/d18dcfe9860e842f394e37ba01ca9440ab2178f4 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43882 – exec: Fix ToCToU between perm check and set-uid/gid usage
https://notcve.org/view.php?id=CVE-2024-43882
In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. • https://git.kernel.org/stable/c/d5c3c7e26275a2d83b894d30f7582a42853a958f https://git.kernel.org/stable/c/368f6985d46657b8b466a421dddcacd4051f7ada https://git.kernel.org/stable/c/15469d46ba34559bfe7e3de6659115778c624759 https://git.kernel.org/stable/c/9b424c5d4130d56312e2a3be17efb0928fec4d64 https://git.kernel.org/stable/c/f6cfc6bcfd5e1cf76115b6450516ea4c99897ae1 https://git.kernel.org/stable/c/d2a2a4714d80d09b0f8eb6438ab4224690b7121e https://git.kernel.org/stable/c/90dfbba89ad4f0d9c9744ecbb1adac4aa2ff4f3e https://git.kernel.org/stable/c/f50733b45d865f91db90919f8311e2127 •
CVSS: 4.7EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43880 – mlxsw: spectrum_acl_erp: Fix object nesting warning
https://notcve.org/view.php?id=CVE-2024-43880
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_erp: Fix object nesting warning ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM (A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can contain more ACLs (i.e., tc filters), but the number of masks in each region (i.e., tc chain) is limited. In order to mitigate the effects of the above limitation, the device allows filters to share a single mask if their masks only differ in up to 8 consecutive bits. For example, dst_ip/25 can be represented using dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the number of masks being used (and therefore does not support mask aggregation), but can contain a limited number of filters. The driver uses the "objagg" library to perform the mask aggregation by passing it objects that consist of the filter's mask and whether the filter is to be inserted into the A-TCAM or the C-TCAM since filters in different TCAMs cannot share a mask. The set of created objects is dependent on the insertion order of the filters and is not necessarily optimal. Therefore, the driver will periodically ask the library to compute a more optimal set ("hints") by looking at all the existing objects. When the library asks the driver whether two objects can be aggregated the driver only compares the provided masks and ignores the A-TCAM / C-TCAM indication. • https://git.kernel.org/stable/c/9069a3817d82b01b3a55da382c774e3575946130 https://git.kernel.org/stable/c/4dc09f6f260db3c4565a4ec52ba369393598f2fb https://git.kernel.org/stable/c/36a9996e020dd5aa325e0ecc55eb2328288ea6bb https://git.kernel.org/stable/c/9a5261a984bba4f583d966c550fa72c33ff3714e https://git.kernel.org/stable/c/25c6fd9648ad05da493a5d30881896a78a08b624 https://git.kernel.org/stable/c/0e59c2d22853266704e127915653598f7f104037 https://git.kernel.org/stable/c/fb5d4fc578e655d113f09565f6f047e15f7ab578 https://git.kernel.org/stable/c/97d833ceb27dc19f8777d63f90be4a27b • CWE-284: Improper Access Control •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43879 – wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
https://notcve.org/view.php?id=CVE-2024-43879
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he() Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. • https://git.kernel.org/stable/c/c4cbaf7973a794839af080f13748335976cf3f3f https://git.kernel.org/stable/c/45d20a1c54be4f3173862c7b950d4468447814c9 https://git.kernel.org/stable/c/b289ebb0516526cb4abae081b7ec29fd4fa1209d https://git.kernel.org/stable/c/2e201b3d162c6c49417c438ffb30b58c9f85769f https://git.kernel.org/stable/c/576c64622649f3ec07e97bac8fec8b8a2ef4d086 https://git.kernel.org/stable/c/16ad67e73309db0c20cc2a651992bd01c05e6b27 https://git.kernel.org/stable/c/67b5f1054197e4f5553047759c15c1d67d4c8142 https://git.kernel.org/stable/c/19eaf4f2f5a981f55a265242ada2bf92b • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •