Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: Fix a credential leak in _nfs4_discover_trunking()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: virtual_ncidev: Fix memory leak in virtual_nci_send()<br /> <br /> skb should be free in virtual_nci_send(), otherwise kmemleak will report<br /> memleak.<br /> <br /> Steps for reproduction (simulated in qemu):<br /> cd tools/testing/selftests/nci<br /> make<br /> ./nci_dev<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888107588000 (size 208):<br /> comm "nci_dev", pid 206, jiffies 4294945376 (age 368.248s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __alloc_skb+0x1da/0x290<br /> [] nci_send_cmd+0xa3/0x350<br /> [] nci_reset_req+0x6b/0xa0<br /> [] __nci_request+0x90/0x250<br /> [] nci_dev_up+0x217/0x5b0<br /> [] nfc_dev_up+0x114/0x220<br /> [] nfc_genl_dev_up+0x94/0xe0<br /> [] genl_family_rcv_msg_doit.isra.14+0x228/0x2d0<br /> [] genl_rcv_msg+0x35c/0x640<br /> [] netlink_rcv_skb+0x11e/0x350<br /> [] genl_rcv+0x24/0x40<br /> [] netlink_unicast+0x43f/0x640<br /> [] netlink_sendmsg+0x73a/0xbf0<br /> [] __sys_sendto+0x324/0x370<br /> [] __x64_sys_sendto+0xdd/0x1b0<br /> [] do_syscall_64+0x3f/0x90

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: prevent leak of lsm program after failed attach<br /> <br /> In [0], we added the ability to bpf_prog_attach LSM programs to cgroups,<br /> but in our validation to make sure the prog is meant to be attached to<br /> BPF_LSM_CGROUP, we return too early if the check fails. This results in<br /> lack of decrementing prog&amp;#39;s refcnt (through bpf_prog_put)<br /> leaving the LSM program alive past the point of the expected lifecycle.<br /> This fix allows for the decrement to take place.<br /> <br /> [0] https://lore.kernel.org/all/20220628174314.1216643-4-sdf@google.com/

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().