CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50016 – drm/amd/display: Avoid overflow assignment in link_dp_cts
https://notcve.org/view.php?id=CVE-2024-50016
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity. • https://git.kernel.org/stable/c/a1495acc6234fa79b775599d3f49009afd53299f https://git.kernel.org/stable/c/26ced9d86240868f5b41708ceee02e6ec2924498 https://git.kernel.org/stable/c/adeed800bc30ef718478b28c08f79231e5980e3d https://git.kernel.org/stable/c/a15268787b79fd183dd526cc16bec9af4f4e49a1 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50015 – ext4: dax: fix overflowing extents beyond inode size when partially writing
https://notcve.org/view.php?id=CVE-2024-50015
In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected. • https://git.kernel.org/stable/c/776722e85d3b0936253ecc3d14db4fba37f191ba https://git.kernel.org/stable/c/f8a7c342326f6ad1dfdb30a18dd013c70f5e9669 https://git.kernel.org/stable/c/8c30a9a8610c314554997f86370140746aa35661 https://git.kernel.org/stable/c/abfaa876b948baaea4d14f21a1963789845c8b4c https://git.kernel.org/stable/c/5efccdee4a7d507a483f20f880b809cc4eaef14d https://git.kernel.org/stable/c/a9f331f51515bdb3ebc8d0963131af367ef468f6 https://git.kernel.org/stable/c/ec0dd451e236c46e4858d53e9e82bae7797a7af5 https://git.kernel.org/stable/c/dda898d7ffe85931f9cca6d702a51f337 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50014 – ext4: fix access to uninitialised lock in fc replay path
https://notcve.org/view.php?id=CVE-2024-50014
In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? • https://git.kernel.org/stable/c/d157fc20ca5239fd56965a5a8aa1a0e25919891a https://git.kernel.org/stable/c/b002031d585a14eed511117dda8c6452a804d508 https://git.kernel.org/stable/c/23dfdb56581ad92a9967bcd720c8c23356af74c1 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50013 – exfat: fix memory leak in exfat_load_bitmap()
https://notcve.org/view.php?id=CVE-2024-50013
In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak. • https://git.kernel.org/stable/c/1e49a94cf707204b66a3fb242f2814712c941f52 https://git.kernel.org/stable/c/f692160d3e1e5450605071b8df8f7d08d9b09a83 https://git.kernel.org/stable/c/ddf704c2ce3b73f38d2dd8cf1bb0f7ec038bdf63 https://git.kernel.org/stable/c/4e1813e52f86eb8db0c6c9570251f2fcbc571f5d https://git.kernel.org/stable/c/bf0b3b35259475d1fe377bcaa565488e26684f7a https://git.kernel.org/stable/c/dca359db1eb37f334267ebd7e3cab9a66d191d5b https://git.kernel.org/stable/c/89081e8407e637463db5880d168e3652fb9f4330 https://git.kernel.org/stable/c/d2b537b3e533f28e0d97293fe9293161f •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50012 – cpufreq: Avoid a bad reference count on CPU node
https://notcve.org/view.php?id=CVE-2024-50012
In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute. • https://git.kernel.org/stable/c/6c3d8387839252f1a0fc6367f314446e4a2ebd0b https://git.kernel.org/stable/c/0f41f383b5a61a2bf6429a449ebba7fb08179d81 https://git.kernel.org/stable/c/77f88b17387a017416babf1e6488fa17682287e2 https://git.kernel.org/stable/c/47cb1d9278f179df8250304ec41009e3e836a926 https://git.kernel.org/stable/c/c0f02536fffbbec71aced36d52a765f8c4493dc2 •