CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48809 – net: fix a memleak when uncloning an skb dst and its metadata
https://notcve.org/view.php?id=CVE-2022-48809
In the Linux kernel, the following vulnerability has been resolved: net: fix a memleak when uncloning an skb dst and its metadata When uncloning an skb dst and its associated metadata, a new dst+metadata is allocated and later replaces the old one in the skb. This is helpful to have a non-shared dst+metadata attached to a specific skb. The issue is the uncloned dst+metadata is initialized with a refcount of 1, which is increased to 2 before attaching it to the skb. When tun_dst_unclone returns, the dst+metadata is only referenced from a single place (the skb) while its refcount is 2. Its refcount will never drop to 0 (when the skb is consumed), leading to a memory leak. Fix this by removing the call to dst_hold in tun_dst_unclone, as the dst+metadata refcount is already 1. • https://git.kernel.org/stable/c/fc4099f17240767554ff3a73977acb78ef615404 https://git.kernel.org/stable/c/4ac84498fbe84a00e7aef185e2bb3e40ce71eca4 https://git.kernel.org/stable/c/c1ff27d100e2670b03cbfddb9117e5f9fc672540 https://git.kernel.org/stable/c/0be943916d781df2b652793bb2d3ae4f9624c10a https://git.kernel.org/stable/c/a80817adc2a4c1ba26a7aa5f3ed886e4a18dff88 https://git.kernel.org/stable/c/00e6d6c3bc14dfe32824e2c515f0e0f2d6ecf2f1 https://git.kernel.org/stable/c/fdcb263fa5cda15b8cb24a641fa2718c47605314 https://git.kernel.org/stable/c/8b1087b998e273f07be13dcb5f3ca4c30 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48806 – eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX
https://notcve.org/view.php?id=CVE-2022-48806
In the Linux kernel, the following vulnerability has been resolved: eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX Commit effa453168a7 ("i2c: i801: Don't silently correct invalid transfer size") revealed that ee1004_eeprom_read() did not properly limit how many bytes to read at once. In particular, i2c_smbus_read_i2c_block_data_or_emulated() takes the length to read as an u8. If count == 256 after taking into account the offset and page boundary, the cast to u8 overflows. And this is common when user space tries to read the entire EEPROM at once. To fix it, limit each read to I2C_SMBUS_BLOCK_MAX (32) bytes, already the maximum length i2c_smbus_read_i2c_block_data_or_emulated() allows. • https://git.kernel.org/stable/c/aca56c298e2a6d20ab6308e203a8d37f2a7759d3 https://git.kernel.org/stable/c/25714ad6bf5e98025579fa4c08ff2041a663910c https://git.kernel.org/stable/c/be9313f755a7bfa02230b15731d07074d5255ecb https://git.kernel.org/stable/c/07d9beb6e3c2e852e884113d6803ea4b3643ae38 https://git.kernel.org/stable/c/74650c34f93044d3ab441235f161f9e1e761e96b https://git.kernel.org/stable/c/a126a8c3dd51519513141b4fc94fd4813bca2c0f https://git.kernel.org/stable/c/202d0e22fe512df0f1cb6253d40ce1058e373247 https://git.kernel.org/stable/c/7414af7bdad9a9cddb3a765ca98ea2070 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48805 – net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup
https://notcve.org/view.php?id=CVE-2022-48805
In the Linux kernel, the following vulnerability has been resolved: net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup ax88179_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data. I have tested that this can be used by a malicious USB device to send a bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response that contains random kernel heap data. It's probably also possible to get OOB writes from this on a little-endian system somehow - maybe by triggering skb_cow() via IP options processing -, but I haven't tested that. • https://git.kernel.org/stable/c/e2ca90c276e1fc410d7cd3c1a4eee245ec902a20 https://git.kernel.org/stable/c/711b6bf3fb052f0a6b5b3205d50e30c0c2980382 https://git.kernel.org/stable/c/63f0cfb36c1f1964a59ce544156677601e2d8740 https://git.kernel.org/stable/c/1668781ed24da43498799aa4f65714a7de201930 https://git.kernel.org/stable/c/a0fd5492ee769029a636f1fb521716b022b1423d https://git.kernel.org/stable/c/758290defe93a865a2880d10c5d5abd288b64b5d https://git.kernel.org/stable/c/ffd0393adcdcefab7e131488e10dcfde5e02d6eb https://git.kernel.org/stable/c/9681823f96a811268265f35307072ad80 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48804 – vt_ioctl: fix array_index_nospec in vt_setactivate
https://notcve.org/view.php?id=CVE-2022-48804
In the Linux kernel, the following vulnerability has been resolved: vt_ioctl: fix array_index_nospec in vt_setactivate array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam. • https://git.kernel.org/stable/c/830c5aa302ec16b4ee641aec769462c37f802c90 https://git.kernel.org/stable/c/2a45a6bd1e6d651770aafff57ab3e1d3bb0b42e0 https://git.kernel.org/stable/c/170325aba4608bde3e7d21c9c19b7bc266ac0885 https://git.kernel.org/stable/c/ae3d57411562260ee3f4fd5e875f410002341104 https://git.kernel.org/stable/c/778302ca09498b448620edd372dc908bebf80bdf https://git.kernel.org/stable/c/ffe54289b02e9c732d6f04c8ebbe3b2d90d32118 https://git.kernel.org/stable/c/6550bdf52846f85a2a3726a5aa0c7c4399f2fc02 https://git.kernel.org/stable/c/61cc70d9e8ef5b042d4ed87994d20100e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48802 – fs/proc: task_mmu.c: don't read mapcount for migration entry
https://notcve.org/view.php?id=CVE-2022-48802
In the Linux kernel, the following vulnerability has been resolved: fs/proc: task_mmu.c: don't read mapcount for migration entry The syzbot reported the below BUG: kernel BUG at include/linux/page-flags.h:785! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline] RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744 Call Trace: page_mapcount include/linux/mm.h:837 [inline] smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466 smaps_pte_entry fs/proc/task_mmu.c:538 [inline] smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601 walk_pmd_range mm/pagewalk.c:128 [inline] walk_pud_range mm/pagewalk.c:205 [inline] walk_p4d_range mm/pagewalk.c:240 [inline] walk_pgd_range mm/pagewalk.c:277 [inline] __walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379 walk_page_vma+0x277/0x350 mm/pagewalk.c:530 smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768 smap_gather_stats fs/proc/task_mmu.c:741 [inline] show_smap+0xc6/0x440 fs/proc/task_mmu.c:822 seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272 seq_read+0x3e0/0x5b0 fs/seq_file.c:162 vfs_read+0x1b5/0x600 fs/read_write.c:479 ksys_read+0x12d/0x250 fs/read_write.c:619 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae The reproducer was trying to read /proc/$PID/smaps when calling MADV_FREE at the mean time. MADV_FREE may split THPs if it is called for partial THP. It may trigger the below race: CPU A CPU B ----- ----- smaps walk: MADV_FREE: page_mapcount() PageCompound() split_huge_page() page = compound_head(page) PageDoubleMap(page) When calling PageDoubleMap() this page is not a tail page of THP anymore so the BUG is triggered. This could be fixed by elevated refcount of the page before calling mapcount, but that would prevent it from counting migration entries, and it seems overkilling because the race just could happen when PMD is split so all PTE entries of tail pages are actually migration entries, and smaps_account() does treat migration entries as mapcount == 1 as Kirill pointed out. Add a new parameter for smaps_account() to tell this entry is migration entry then skip calling page_mapcount(). Don't skip getting mapcount for device private entries since they do track references with mapcount. Pagemap also has the similar issue although it was not reported. • https://git.kernel.org/stable/c/e9b61f19858a5d6c42ce2298cf138279375d0d9b https://git.kernel.org/stable/c/db3f3636e4aed2cba3e4e7897a053323f7a62249 https://git.kernel.org/stable/c/a8dd0cfa37792863b6c4bf9542975212a6715d49 https://git.kernel.org/stable/c/05d3f8045efa59457b323caf00bdb9273b7962fa https://git.kernel.org/stable/c/24d7275ce2791829953ed4e72f68277ceb2571c6 •