Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix memory leak in ocfs2_stack_glue_init()<br /> <br /> ocfs2_table_header should be free in ocfs2_stack_glue_init() if<br /> ocfs2_sysfs_init() failed, otherwise kmemleak will report memleak.<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810eeb5800 (size 128):<br /> comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s)<br /> hex dump (first 32 bytes):<br /> c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@..............<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __register_sysctl_table+0xca/0xef0<br /> [] 0xffffffffa0050037<br /> [] do_one_initcall+0xdb/0x480<br /> [] do_init_module+0x1cf/0x680<br /> [] load_module+0x6441/0x6f20<br /> [] __do_sys_finit_module+0x12f/0x1c0<br /> [] do_syscall_64+0x3f/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: annotate data-races around kcm-&gt;rx_psock<br /> <br /> kcm-&gt;rx_psock can be read locklessly in kcm_rfree().<br /> Annotate the read and writes accordingly.<br /> <br /> We do the same for kcm-&gt;rx_wait in the following patch.<br /> <br /> syzbot reported:<br /> BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm<br /> <br /> write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:<br /> unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313<br /> kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373<br /> __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301<br /> strp_recv+0x6d/0x80 net/strparser/strparser.c:335<br /> tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703<br /> strp_read_sock net/strparser/strparser.c:358 [inline]<br /> do_strp_work net/strparser/strparser.c:406 [inline]<br /> strp_work+0xe8/0x180 net/strparser/strparser.c:415<br /> process_one_work+0x3d3/0x720 kernel/workqueue.c:2289<br /> worker_thread+0x618/0xa70 kernel/workqueue.c:2436<br /> kthread+0x1a9/0x1e0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0:<br /> kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181<br /> skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841<br /> skb_release_all net/core/skbuff.c:852 [inline]<br /> __kfree_skb net/core/skbuff.c:868 [inline]<br /> kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891<br /> kfree_skb include/linux/skbuff.h:1216 [inline]<br /> kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161<br /> ____sys_recvmsg+0x16c/0x2e0<br /> ___sys_recvmsg net/socket.c:2743 [inline]<br /> do_recvmmsg+0x2f1/0x710 net/socket.c:2837<br /> __sys_recvmmsg net/socket.c:2916 [inline]<br /> __do_sys_recvmmsg net/socket.c:2939 [inline]<br /> __se_sys_recvmmsg net/socket.c:2932 [inline]<br /> __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0xffff88812971ce00 -&gt; 0x0000000000000000<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: fix bridge lifetime<br /> <br /> Device-managed resources allocated post component bind must be tied to<br /> the lifetime of the aggregate DRM device or they will not necessarily be<br /> released when binding of the aggregate device is deferred.<br /> <br /> This can lead resource leaks or failure to bind the aggregate device<br /> when binding is later retried and a second attempt to allocate the<br /> resources is made.<br /> <br /> For the DP bridges, previously allocated bridges will leak on probe<br /> deferral.<br /> <br /> Fix this by amending the DP parser interface and tying the lifetime of<br /> the bridge device to the DRM device rather than DP platform device.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/502667/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range<br /> <br /> If we get -ENOMEM while dropping file extent items in a given range, at<br /> btrfs_drop_extents(), due to failure to allocate memory when attempting to<br /> increment the reference count for an extent or drop the reference count,<br /> we handle it with a BUG_ON(). This is excessive, instead we can simply<br /> abort the transaction and return the error to the caller. In fact most<br /> callers of btrfs_drop_extents(), directly or indirectly, already abort<br /> the transaction if btrfs_drop_extents() returns any error.<br /> <br /> Also, we already have error paths at btrfs_drop_extents() that may return<br /> -ENOMEM and in those cases we abort the transaction, like for example<br /> anything that changes the b+tree may return -ENOMEM due to a failure to<br /> allocate a new extent buffer when COWing an existing extent buffer, such<br /> as a call to btrfs_duplicate_item() for example.<br /> <br /> So replace the BUG_ON() calls with proper logic to abort the transaction<br /> and return the error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: libertas: fix memory leak in lbs_init_adapter()<br /> <br /> When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not<br /> released. Add free memory to processing error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/msg_ring: Fix NULL pointer dereference in io_msg_send_fd()<br /> <br /> Syzkaller produced the below call trace:<br /> <br /> BUG: KASAN: null-ptr-deref in io_msg_ring+0x3cb/0x9f0<br /> Write of size 8 at addr 0000000000000070 by task repro/16399<br /> <br /> CPU: 0 PID: 16399 Comm: repro Not tainted 6.1.0-rc1 #28<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xcd/0x134<br /> ? io_msg_ring+0x3cb/0x9f0<br /> kasan_report+0xbc/0xf0<br /> ? io_msg_ring+0x3cb/0x9f0<br /> kasan_check_range+0x140/0x190<br /> io_msg_ring+0x3cb/0x9f0<br /> ? io_msg_ring_prep+0x300/0x300<br /> io_issue_sqe+0x698/0xca0<br /> io_submit_sqes+0x92f/0x1c30<br /> __do_sys_io_uring_enter+0xae4/0x24b0<br /> ....<br /> RIP: 0033:0x7f2eaf8f8289<br /> RSP: 002b:00007fff40939718 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2eaf8f8289<br /> RDX: 0000000000000000 RSI: 0000000000006f71 RDI: 0000000000000004<br /> RBP: 00007fff409397a0 R08: 0000000000000000 R09: 0000000000000039<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004006d0<br /> R13: 00007fff40939880 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> Kernel panic - not syncing: panic_on_warn set ...<br /> <br /> We don&amp;#39;t have a NULL check on file_ptr in io_msg_send_fd() function,<br /> so when file_ptr is NUL src_file is also NULL and get_file()<br /> dereferences a NULL pointer and leads to above crash.<br /> <br /> Add a NULL check to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> UM: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK<br /> <br /> When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,<br /> cpu_max_bits_warn() generates a runtime warning similar as below while<br /> we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)<br /> instead of NR_CPUS to iterate CPUs.<br /> <br /> [ 3.052463] ------------[ cut here ]------------<br /> [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0<br /> [ 3.070072] Modules linked in: efivarfs autofs4<br /> [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052<br /> [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000<br /> [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430<br /> [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff<br /> [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890<br /> [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa<br /> [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000<br /> [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000<br /> [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000<br /> [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286<br /> [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c<br /> [ 3.195868] ...<br /> [ 3.199917] Call Trace:<br /> [ 3.203941] [] show_stack+0x38/0x14c<br /> [ 3.210666] [] dump_stack_lvl+0x60/0x88<br /> [ 3.217625] [] __warn+0xd0/0x100<br /> [ 3.223958] [] warn_slowpath_fmt+0x7c/0xcc<br /> [ 3.231150] [] show_cpuinfo+0x5e8/0x5f0<br /> [ 3.238080] [] seq_read_iter+0x354/0x4b4<br /> [ 3.245098] [] new_sync_read+0x17c/0x1c4<br /> [ 3.252114] [] vfs_read+0x138/0x1d0<br /> [ 3.258694] [] ksys_read+0x70/0x100<br /> [ 3.265265] [] do_syscall+0x7c/0x94<br /> [ 3.271820] [] handle_syscall+0xc4/0x160<br /> [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pnode: terminate at peers of source<br /> <br /> The propagate_mnt() function handles mount propagation when creating<br /> mounts and propagates the source mount tree @source_mnt to all<br /> applicable nodes of the destination propagation mount tree headed by<br /> @dest_mnt.<br /> <br /> Unfortunately it contains a bug where it fails to terminate at peers of<br /> @source_mnt when looking up copies of the source mount that become<br /> masters for copies of the source mount tree mounted on top of slaves in<br /> the destination propagation tree causing a NULL dereference.<br /> <br /> Once the mechanics of the bug are understood it&amp;#39;s easy to trigger.<br /> Because of unprivileged user namespaces it is available to unprivileged<br /> users.<br /> <br /> While fixing this bug we&amp;#39;ve gotten confused multiple times due to<br /> unclear terminology or missing concepts. So let&amp;#39;s start this with some<br /> clarifications:<br /> <br /> * The terms "master" or "peer" denote a shared mount. A shared mount<br /> belongs to a peer group.<br /> <br /> * A peer group is a set of shared mounts that propagate to each other.<br /> They are identified by a peer group id. The peer group id is available<br /> in @shared_mnt-&gt;mnt_group_id.<br /> Shared mounts within the same peer group have the same peer group id.<br /> The peers in a peer group can be reached via @shared_mnt-&gt;mnt_share.<br /> <br /> * The terms "slave mount" or "dependent mount" denote a mount that<br /> receives propagation from a peer in a peer group. IOW, shared mounts<br /> may have slave mounts and slave mounts have shared mounts as their<br /> master. Slave mounts of a given peer in a peer group are listed on<br /> that peers slave list available at @shared_mnt-&gt;mnt_slave_list.<br /> <br /> * The term "master mount" denotes a mount in a peer group. IOW, it<br /> denotes a shared mount or a peer mount in a peer group. The term<br /> "master mount" - or "master" for short - is mostly used when talking<br /> in the context of slave mounts that receive propagation from a master<br /> mount. A master mount of a slave identifies the closest peer group a<br /> slave mount receives propagation from. The master mount of a slave can<br /> be identified via @slave_mount-&gt;mnt_master. Different slaves may point<br /> to different masters in the same peer group.<br /> <br /> * Multiple peers in a peer group can have non-empty -&gt;mnt_slave_lists.<br /> Non-empty -&gt;mnt_slave_lists of peers don&amp;#39;t intersect. Consequently, to<br /> ensure all slave mounts of a peer group are visited the<br /> -&gt;mnt_slave_lists of all peers in a peer group have to be walked.<br /> <br /> * Slave mounts point to a peer in the closest peer group they receive<br /> propagation from via @slave_mnt-&gt;mnt_master (see above). Together with<br /> these peers they form a propagation group (see below). The closest<br /> peer group can thus be identified through the peer group id<br /> @slave_mnt-&gt;mnt_master-&gt;mnt_group_id of the peer/master that a slave<br /> mount receives propagation from.<br /> <br /> * A shared-slave mount is a slave mount to a peer group pg1 while also<br /> a peer in another peer group pg2. IOW, a peer group may receive<br /> propagation from another peer group.<br /> <br /> If a peer group pg1 is a slave to another peer group pg2 then all<br /> peers in peer group pg1 point to the same peer in peer group pg2 via<br /> -&gt;mnt_master. IOW, all peers in peer group pg1 appear on the same<br /> -&gt;mnt_slave_list. IOW, they cannot be slaves to different peer groups.<br /> <br /> * A pure slave mount is a slave mount that is a slave to a peer group<br /> but is not a peer in another peer group.<br /> <br /> * A propagation group denotes the set of mounts consisting of a single<br /> peer group pg1 and all slave mounts and shared-slave mounts that point<br /> to a peer in that peer group via -&gt;mnt_master. IOW, all slave mounts<br /> such that @slave_mnt-&gt;mnt_master-&gt;mnt_group_id is equal to<br /> @shared_mnt-&gt;mnt_group_id.<br /> <br /> The concept of a propagation group makes it easier to talk about a<br /> single propagation level in a propagation tree.<br /> <br /> For example, in propagate_mnt() the immediate peers of @dest_mnt and<br /> all slaves of @dest_mnt&amp;#39;s peer group form a propagation group pr<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create()<br /> <br /> In error case in bridge_platform_create after calling<br /> platform_device_add()/platform_device_add_data()/<br /> platform_device_add_resources(), release the failed<br /> &amp;#39;pdev&amp;#39; or it will be leak, call platform_device_put()<br /> to fix this problem.<br /> <br /> Besides, &amp;#39;pdev&amp;#39; is divided into &amp;#39;pdev_wd&amp;#39; and &amp;#39;pdev_bd&amp;#39;,<br /> use platform_device_unregister() to release sgi_w1<br /> resources when xtalk-bridge registration fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> chardev: fix error handling in cdev_device_add()<br /> <br /> While doing fault injection test, I got the following report:<br /> <br /> ------------[ cut here ]------------<br /> kobject: &amp;#39;(null)&amp;#39; (0000000039956980): is not initialized, yet kobject_put() is being called.<br /> WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0<br /> CPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:kobject_put+0x23d/0x4e0<br /> Call Trace:<br /> <br /> cdev_device_add+0x15e/0x1b0<br /> __iio_device_register+0x13b4/0x1af0 [industrialio]<br /> __devm_iio_device_register+0x22/0x90 [industrialio]<br /> max517_probe+0x3d8/0x6b4 [max517]<br /> i2c_device_probe+0xa81/0xc00<br /> <br /> When device_add() is injected fault and returns error, if dev-&gt;devt is not set,<br /> cdev_add() is not called, cdev_del() is not needed. Fix this by checking dev-&gt;devt<br /> in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: core: add missing of_node_get() in dynamic partitions code<br /> <br /> This fixes unbalanced of_node_put():<br /> [ 1.078910] 6 cmdlinepart partitions found on MTD device gpmi-nand<br /> [ 1.085116] Creating 6 MTD partitions on "gpmi-nand":<br /> [ 1.090181] 0x000000000000-0x000008000000 : "nandboot"<br /> [ 1.096952] 0x000008000000-0x000009000000 : "nandfit"<br /> [ 1.103547] 0x000009000000-0x00000b000000 : "nandkernel"<br /> [ 1.110317] 0x00000b000000-0x00000c000000 : "nanddtb"<br /> [ 1.115525] ------------[ cut here ]------------<br /> [ 1.120141] refcount_t: addition on 0; use-after-free.<br /> [ 1.125328] WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xdc/0x148<br /> [ 1.133528] Modules linked in:<br /> [ 1.136589] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7-next-20220930-04543-g8cf3f7<br /> [ 1.146342] Hardware name: Freescale i.MX8DXL DDR3L EVK (DT)<br /> [ 1.151999] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1.158965] pc : refcount_warn_saturate+0xdc/0x148<br /> [ 1.163760] lr : refcount_warn_saturate+0xdc/0x148<br /> [ 1.168556] sp : ffff800009ddb080<br /> [ 1.171866] x29: ffff800009ddb080 x28: ffff800009ddb35a x27: 0000000000000002<br /> [ 1.179015] x26: ffff8000098b06ad x25: ffffffffffffffff x24: ffff0a00ffffff05<br /> [ 1.186165] x23: ffff00001fdf6470 x22: ffff800009ddb367 x21: 0000000000000000<br /> [ 1.193314] x20: ffff00001fdfebe8 x19: ffff00001fdfec50 x18: ffffffffffffffff<br /> [ 1.200464] x17: 0000000000000000 x16: 0000000000000118 x15: 0000000000000004<br /> [ 1.207614] x14: 0000000000000fff x13: ffff800009bca248 x12: 0000000000000003<br /> [ 1.214764] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 4762cb2ccb52de00<br /> [ 1.221914] x8 : 4762cb2ccb52de00 x7 : 205d313431303231 x6 : 312e31202020205b<br /> [ 1.229063] x5 : ffff800009d55c1f x4 : 0000000000000001 x3 : 0000000000000000<br /> [ 1.236213] x2 : 0000000000000000 x1 : ffff800009954be6 x0 : 000000000000002a<br /> [ 1.243365] Call trace:<br /> [ 1.245806] refcount_warn_saturate+0xdc/0x148<br /> [ 1.250253] kobject_get+0x98/0x9c<br /> [ 1.253658] of_node_get+0x20/0x34<br /> [ 1.257072] of_fwnode_get+0x3c/0x54<br /> [ 1.260652] fwnode_get_nth_parent+0xd8/0xf4<br /> [ 1.264926] fwnode_full_name_string+0x3c/0xb4<br /> [ 1.269373] device_node_string+0x498/0x5b4<br /> [ 1.273561] pointer+0x41c/0x5d0<br /> [ 1.276793] vsnprintf+0x4d8/0x694<br /> [ 1.280198] vprintk_store+0x164/0x528<br /> [ 1.283951] vprintk_emit+0x98/0x164<br /> [ 1.287530] vprintk_default+0x44/0x6c<br /> [ 1.291284] vprintk+0xf0/0x134<br /> [ 1.294428] _printk+0x54/0x7c<br /> [ 1.297486] of_node_release+0xe8/0x128<br /> [ 1.301326] kobject_put+0x98/0xfc<br /> [ 1.304732] of_node_put+0x1c/0x28<br /> [ 1.308137] add_mtd_device+0x484/0x6d4<br /> [ 1.311977] add_mtd_partitions+0xf0/0x1d0<br /> [ 1.316078] parse_mtd_partitions+0x45c/0x518<br /> [ 1.320439] mtd_device_parse_register+0xb0/0x274<br /> [ 1.325147] gpmi_nand_probe+0x51c/0x650<br /> [ 1.329074] platform_probe+0xa8/0xd0<br /> [ 1.332740] really_probe+0x130/0x334<br /> [ 1.336406] __driver_probe_device+0xb4/0xe0<br /> [ 1.340681] driver_probe_device+0x3c/0x1f8<br /> [ 1.344869] __driver_attach+0xdc/0x1a4<br /> [ 1.348708] bus_for_each_dev+0x80/0xcc<br /> [ 1.352548] driver_attach+0x24/0x30<br /> [ 1.356127] bus_add_driver+0x108/0x1f4<br /> [ 1.359967] driver_register+0x78/0x114<br /> [ 1.363807] __platform_driver_register+0x24/0x30<br /> [ 1.368515] gpmi_nand_driver_init+0x1c/0x28<br /> [ 1.372798] do_one_initcall+0xbc/0x238<br /> [ 1.376638] do_initcall_level+0x94/0xb4<br /> [ 1.380565] do_initcalls+0x54/0x94<br /> [ 1.384058] do_basic_setup+0x1c/0x28<br /> [ 1.387724] kernel_init_freeable+0x110/0x188<br /> [ 1.392084] kernel_init+0x20/0x1a0<br /> [ 1.395578] ret_from_fork+0x10/0x20<br /> [ 1.399157] ---[ end trace 0000000000000000 ]---<br /> [ 1.403782] ------------[ cut here ]------------