Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix xid leak in cifs_ses_add_channel()<br /> <br /> Before return, should free the xid, otherwise, the<br /> xid will be leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rapidio: rio: fix possible name leak in rio_register_mport()<br /> <br /> If device_register() returns error, the name allocated by dev_set_name()<br /> need be freed. It should use put_device() to give up the reference in the<br /> error path, so that the name can be freed in kobject_cleanup(), and<br /> list_del() is called to delete the port from rio_mports.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: alcor: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value, the memory<br /> that allocated in mmc_alloc_host() will be leaked and it will lead a kernel<br /> crash because of deleting not added device in the remove path.<br /> <br /> So fix this by checking the return value and calling mmc_free_host() in the<br /> error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix the error length of VALIDATE_NEGOTIATE_INFO message<br /> <br /> Commit d5c7076b772a ("smb3: add smb3.1.1 to default dialect list")<br /> extend the dialects from 3 to 4, but forget to decrease the extended<br /> length when specific the dialect, then the message length is larger<br /> than expected.<br /> <br /> This maybe leak some info through network because not initialize the<br /> message body.<br /> <br /> After apply this patch, the VALIDATE_NEGOTIATE_INFO message length is<br /> reduced from 28 bytes to 26 bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: Fix memleak in alloc_ns()<br /> <br /> After changes in commit a1bd627b46d1 ("apparmor: share profile name on<br /> replacement"), the hname member of struct aa_policy is not valid slab<br /> object, but a subset of that, it can not be freed by kfree_sensitive(),<br /> use aa_policy_destroy() to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Finish converting the NFSv2 GETACL result encoder<br /> <br /> The xdr_stream conversion inadvertently left some code that set the<br /> page_len of the send buffer. The XDR stream encoders should handle<br /> this automatically now.<br /> <br /> This oversight adds garbage past the end of the Reply message.<br /> Clients typically ignore the garbage, but NFSD does not need to send<br /> it, as it leaks stale memory contents onto the wire.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: prevent decl_tag from being referenced in func_proto<br /> <br /> Syzkaller was able to hit the following issue:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 3609 at kernel/bpf/btf.c:1946<br /> btf_type_id_size+0x2d5/0x9d0 kernel/bpf/btf.c:1946<br /> Modules linked in:<br /> CPU: 0 PID: 3609 Comm: syz-executor361 Not tainted<br /> 6.0.0-syzkaller-02734-g0326074ff465 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS<br /> Google 09/22/2022<br /> RIP: 0010:btf_type_id_size+0x2d5/0x9d0 kernel/bpf/btf.c:1946<br /> Code: ef e8 7f 8e e4 ff 41 83 ff 0b 77 28 f6 44 24 10 18 75 3f e8 6d 91<br /> e4 ff 44 89 fe bf 0e 00 00 00 e8 20 8e e4 ff e8 5b 91 e4 ff 0b 45<br /> 31 f6 e9 98 02 00 00 41 83 ff 12 74 18 e8 46 91 e4 ff 44<br /> RSP: 0018:ffffc90003cefb40 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000<br /> RDX: ffff8880259c0000 RSI: ffffffff81968415 RDI: 0000000000000005<br /> RBP: ffff88801270ca00 R08: 0000000000000005 R09: 000000000000000e<br /> R10: 0000000000000011 R11: 0000000000000000 R12: 0000000000000000<br /> R13: 0000000000000011 R14: ffff888026ee6424 R15: 0000000000000011<br /> FS: 000055555641b300(0000) GS:ffff8880b9a00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000f2e258 CR3: 000000007110e000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> btf_func_proto_check kernel/bpf/btf.c:4447 [inline]<br /> btf_check_all_types kernel/bpf/btf.c:4723 [inline]<br /> btf_parse_type_sec kernel/bpf/btf.c:4752 [inline]<br /> btf_parse kernel/bpf/btf.c:5026 [inline]<br /> btf_new_fd+0x1926/0x1e70 kernel/bpf/btf.c:6892<br /> bpf_btf_load kernel/bpf/syscall.c:4324 [inline]<br /> __sys_bpf+0xb7d/0x4cf0 kernel/bpf/syscall.c:5010<br /> __do_sys_bpf kernel/bpf/syscall.c:5069 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5067 [inline]<br /> __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:5067<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f0fbae41c69<br /> Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89<br /> f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01<br /> f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffc8aeb6228 EFLAGS: 00000246 ORIG_RAX: 0000000000000141<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0fbae41c69<br /> RDX: 0000000000000020 RSI: 0000000020000140 RDI: 0000000000000012<br /> RBP: 00007f0fbae05e10 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 00000000ffffffff R11: 0000000000000246 R12: 00007f0fbae05ea0<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> <br /> Looks like it tries to create a func_proto which return type is<br /> decl_tag. For the details, see Martin&amp;#39;s spot on analysis in [0].<br /> <br /> 0: https://lore.kernel.org/bpf/CAKH8qBuQDLva_hHxxBuZzyAcYNO4ejhovz6TQeVSk8HY-2SO6g@mail.gmail.com/T/#mea6524b3fcd6298347432226e81b1e6155efc62c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix inode leak in ext4_xattr_inode_create() on an error path<br /> <br /> There is issue as follows when do setxattr with inject fault:<br /> <br /> [localhost]# fsck.ext4 -fn /dev/sda<br /> e2fsck 1.46.6-rc1 (12-Sep-2022)<br /> Pass 1: Checking inodes, blocks, and sizes<br /> Pass 2: Checking directory structure<br /> Pass 3: Checking directory connectivity<br /> Pass 4: Checking reference counts<br /> Unattached zero-length inode 15. Clear? no<br /> <br /> Unattached inode 15<br /> Connect to /lost+found? no<br /> <br /> Pass 5: Checking group summary information<br /> <br /> /dev/sda: ********** WARNING: Filesystem still has errors **********<br /> <br /> /dev/sda: 15/655360 files (0.0% non-contiguous), 66755/2621440 blocks<br /> <br /> This occurs in &amp;#39;ext4_xattr_inode_create()&amp;#39;. If &amp;#39;ext4_mark_inode_dirty()&amp;#39;<br /> fails, dropping i_nlink of the inode is needed. Or will lead to inode leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: via-sdmmc: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value,<br /> it will lead two issues:<br /> 1. The memory that allocated in mmc_alloc_host() is leaked.<br /> 2. In the remove() path, mmc_remove_host() will be called to<br /> delete device, but it&amp;#39;s not added yet, it will lead a kernel<br /> crash because of null-ptr-deref in device_del().<br /> <br /> Fix this by checking the return value and goto error path which<br /> will call mmc_free_host().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: it6505: Initialize AUX channel in it6505_i2c_probe<br /> <br /> During device boot, the HPD interrupt could be triggered before the DRM<br /> subsystem registers it6505 as a DRM bridge. In such cases, the driver<br /> tries to access AUX channel and causes NULL pointer dereference.<br /> Initializing the AUX channel earlier to prevent such error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: dio: fix possible memory leak in dio_init()<br /> <br /> If device_register() returns error, the &amp;#39;dev&amp;#39; and name needs be<br /> freed. Add a release function, and then call put_device() in the<br /> error path, so the name is freed in kobject_cleanup() and to the<br /> &amp;#39;dev&amp;#39; is freed in release function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP<br /> <br /> An oops can be induced by running &amp;#39;cat /proc/kcore &gt; /dev/null&amp;#39; on<br /> devices using pstore with the ram backend because kmap_atomic() assumes<br /> lowmem pages are accessible with __va().<br /> <br /> Unable to handle kernel paging request at virtual address ffffff807ff2b000<br /> Mem abort info:<br /> ESR = 0x96000006<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x06: level 2 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000006<br /> CM = 0, WnR = 0<br /> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000<br /> [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000<br /> Internal error: Oops: 96000006 [#1] PREEMPT SMP<br /> Modules linked in: dm_integrity<br /> CPU: 7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba<br /> Hardware name: Google Lazor (rev3 - 8) (DT)<br /> pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __memcpy+0x110/0x260<br /> lr : vread+0x194/0x294<br /> sp : ffffffc013ee39d0<br /> x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000<br /> x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000<br /> x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21: ffffffc0085a2000<br /> x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60<br /> x14: ffffffffad588000 x13: 0000000000000000 x12: 0000000000000001<br /> x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b<br /> x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 : ffffffc013ee3a78<br /> x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000<br /> Call trace:<br /> __memcpy+0x110/0x260<br /> read_kcore+0x584/0x778<br /> proc_reg_read+0xb4/0xe4<br /> <br /> During early boot, memblock reserves the pages for the ramoops reserved<br /> memory node in DT that would otherwise be part of the direct lowmem<br /> mapping. Pstore&amp;#39;s ram backend reuses those reserved pages to change the<br /> memory type (writeback or non-cached) by passing the pages to vmap()<br /> (see pfn_to_page() usage in persistent_ram_vmap() for more details) with<br /> specific flags. When read_kcore() starts iterating over the vmalloc<br /> region, it runs over the virtual address that vmap() returned for<br /> ramoops. In aligned_vread() the virtual address is passed to<br /> vmalloc_to_page() which returns the page struct for the reserved lowmem<br /> area. That lowmem page is passed to kmap_atomic(), which effectively<br /> calls page_to_virt() that assumes a lowmem page struct must be directly<br /> accessible with __va() and friends. These pages are mapped via vmap()<br /> though, and the lowmem mapping was never made, so accessing them via the<br /> lowmem virtual address oopses like above.<br /> <br /> Let&amp;#39;s side-step this problem by passing VM_IOREMAP to vmap(). This will<br /> tell vread() to not include the ramoops region in the kcore. Instead the<br /> area will look like a bunch of zeros. The alternative is to teach kmap()<br /> about vmalloc areas that intersect with lowmem. Presumably such a change<br /> isn&amp;#39;t a one-liner, and there isn&amp;#39;t much interest in inspecting the<br /> ramoops region in kcore files anyway, so the most expedient route is<br /> taken for now.