CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50018 – net: napi: Prevent overflow of napi_defer_hard_irqs
https://notcve.org/view.php?id=CVE-2024-50018
In the Linux kernel, the following vulnerability has been resolved: net: napi: Prevent overflow of napi_defer_hard_irqs In commit 6f8b12d661d0 ("net: napi: add hard irqs deferral feature") napi_defer_irqs was added to net_device and napi_defer_irqs_count was added to napi_struct, both as type int. This value never goes below zero, so there is not reason for it to be a signed int. Change the type for both from int to u32, and add an overflow check to sysfs to limit the value to S32_MAX. The limit of S32_MAX was chosen because the practical limit before this patch was S32_MAX (anything larger was an overflow) and thus there are no behavioral changes introduced. If the extra bit is needed in the future, the limit can be raised. Before this patch: $ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs' $ cat /sys/class/net/eth4/napi_defer_hard_irqs -2147483647 After this patch: $ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs' bash: line 0: echo: write error: Numerical result out of range Similarly, /sys/class/net/XXXXX/tx_queue_len is defined as unsigned: include/linux/netdevice.h: unsigned int tx_queue_len; And has an overflow check: dev_change_tx_queue_len(..., unsigned long new_len): if (new_len != (unsigned int)new_len) return -ERANGE; • https://git.kernel.org/stable/c/d694ad8b7e5004df86ecd415cb2320d543723672 https://git.kernel.org/stable/c/5e753b743d3b38a3e10be666c32c5434423d0093 https://git.kernel.org/stable/c/08062af0a52107a243f7608fd972edb54ca5b7f8 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50017 – x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
https://notcve.org/view.php?id=CVE-2024-50017
In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. • https://git.kernel.org/stable/c/d80a99892f7a992d103138fa4636b2c33abd6740 https://git.kernel.org/stable/c/a23823098ab2c277c14fc110b97d8d5c83597195 https://git.kernel.org/stable/c/cc31744a294584a36bf764a0ffa3255a8e69f036 •
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 •