The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in protounregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:protounregister+0xee/0x400 Call Trace: <TASK> _dosysdeletemodule+0x318/0x580 dosyscall64+0xc1/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f As bnepinit() ignore bnepsockinit()'s return value, and bnepsockinit() will cleanup all resource. Then when remove bnep module will call bnepsockcleanup() to cleanup sock's resource. To solve above issue just return bnepsockinit()'s return value in bnepexit().(CVE-2024-50148)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, _blockwritebeginint(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.(CVE-2024-50230)
In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [<ffffffe6e7b245dc>] _kmemcacheallocnode+0x1e4/0x2d8 [<ffffffe6e7adde88>] kmalloctrace+0x48/0x110 [<ffffffe6bbd765fc>] ath10kwmitlvopgenmgmttxsend+0xd4/0x1d8 [ath10kcore] [<ffffffe6bbd3eed4>] ath10kmgmtoverwmitxwork+0x134/0x298 [ath10kcore] [<ffffffe6e78d5974>] processscheduledworks+0x1ac/0x400 [<ffffffe6e78d60b8>] workerthread+0x208/0x328 [<ffffffe6e78dc890>] kthread+0x100/0x1c0 [<ffffffe6e78166c0>] retfromfork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmtpendingtx idrremove() operation in ath10kwmitlvopcleanupmgmttxsend() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1(CVE-2024-50236)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in triegetnextkey() triegetnextkey() allocates a node stack with size trie->maxprefixlen, while it writes (trie->maxprefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with maxprefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to triegetnextkey with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2xaremove() Syzkaller is able to provoke null-ptr-dereference in ocfs2xaremove(): [ 57.319872] (a.out,1161,7):ocfs2xaremove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2xacleanupvaluetruncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2xablockwipenamevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? douseraddrfault+0x3e5/0x740 [ 57.333778] ? excpagefault+0x70/0x170 [ 57.334016] ? asmexcpagefault+0x2b/0x30 [ 57.334263] ? _pfxocfs2xablockwipenamevalue+0x10/0x10 [ 57.334596] ? ocfs2xablockwipenamevalue+0x2a/0xc0 [ 57.334913] ocfs2xaremoveentry+0x23/0xc0 [ 57.335164] ocfs2xaset+0x704/0xcf0 [ 57.335381] ? _rawspinunlock+0x1a/0x40 [ 57.335620] ? ocfs2inodecacheunlock+0x16/0x20 [ 57.335915] ? tracepreempton+0x1e/0x70 [ 57.336153] ? startthishandle+0x16c/0x500 [ 57.336410] ? preemptcountsub+0x50/0x80 [ 57.336656] ? rawreadunlock+0x20/0x40 [ 57.336906] ? startthishandle+0x16c/0x500 [ 57.337162] ocfs2xattrblockset+0xa6/0x1e0 [ 57.337424] _ocfs2xattrsethandle+0x1fd/0x5d0 [ 57.337706] ? ocfs2starttrans+0x13d/0x290 [ 57.337971] ocfs2xattrset+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2xattrtrustedset+0x28/0x30 [ 57.338665] ? ocfs2xattrtrustedset+0x28/0x30 [ 57.338948] _vfsremovexattr+0x92/0xc0 [ 57.339182] _vfsremovexattrlocked+0xd5/0x190 [ 57.339456] ? preemptcountsub+0x50/0x80 [ 57.339705] vfsremovexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2xaremove() -> ocfs2xavaluetruncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2xacleanupvaluetruncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2xaremoveentry(loc);' twice: * 1st: in ocfs2xacleanupvaluetruncate(); * 2nd: returning back to ocfs2xaremove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)
In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctpsfootb() A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctpsfootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpdosm+0x181/0x93d0 net/sctp/smsideeffect.c:1166 sctpendpointbhrcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctpinqpush+0x2ef/0x380 net/sctp/inqueue.c:88 sctprcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4rcv+0x42/0x50 net/sctp/protocol.c:1159 ipprotocoldeliverrcu+0xb51/0x13d0 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x336/0x500 net/ipv4/ipinput.c:233(CVE-2024-50299)
In the Linux kernel, the following vulnerability has been resolved: iouring/rw: fix missing NOWAIT check for ODIRECT start write When iouring starts a write, it'll call kiocbstartwrite() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But iouring unconditionally uses kiocbstartwrite(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: _switchto+0x1d8/0x348 _schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpurwsemwait+0x1e8/0x3f8 _percpudownread+0xe8/0x500 iowrite+0xbb8/0xff8 ioissuesqe+0x10c/0x1020 iosubmitsqes+0x614/0x2110 _arm64sysiouringenter+0x524/0x1038 invokesyscall+0x74/0x268 el0svccommon.constprop.0+0x160/0x238 doel0svc+0x44/0x60 el0svc+0x44/0xb0 el0t64synchandler+0x118/0x128 el0t64sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: _switchto+0x1d8/0x348 _schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpudownwrite+0x2b0/0x680 freezesuper+0x248/0x8a8 dovfsioctl+0x149c/0x1b18 _arm64sysioctl+0xd0/0x1a0 invokesyscall+0x74/0x268 el0svccommon.constprop.0+0x160/0x238 doel0svc+0x44/0x60 el0svc+0x44/0xb0 el0t64synchandler+0x118/0x128 el0t64sync+0x168/0x170 Fix this by having the iouring side honor IOCBNOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCBNOWAIT would always be set, this returns -EAGAIN which will have iouring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAPSYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.(CVE-2024-53052)
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported acpievaluateobject() may return AENOTFOUND (failure), which would result in dereferencing buffer.pointer (obj) while being NULL. Although this case may be unrealistic for the current code, it is still better to protect against possible bugs. Bail out also when status is AENOTFOUND. This fixes 1 FORWARDNULL issue reported by Coverity Report: CID 1600951: Null pointer dereferences (FORWARDNULL) (cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1)(CVE-2024-53060)
In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in fromkuid and fromkgid ocfs2setattr() uses attr->iamode, attr->iauid and attr->iagid in a trace point even though ATTRMODE, ATTRUID and ATTRGID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTRMODE, ATTRUID, ATTRGID are initialized, otherwise 0.(CVE-2024-53101)
{ "severity": "High" }
{ "x86_64": [ "bpftool-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "bpftool-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "kernel-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "kernel-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "kernel-debugsource-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "kernel-devel-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "kernel-source-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "kernel-tools-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "kernel-tools-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "kernel-tools-devel-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "perf-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "perf-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "python2-perf-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "python2-perf-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "python3-perf-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm", "python3-perf-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.x86_64.rpm" ], "src": [ "kernel-4.19.90-2412.1.0.0306.oe2003sp4.src.rpm" ], "aarch64": [ "bpftool-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "bpftool-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "kernel-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "kernel-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "kernel-debugsource-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "kernel-devel-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "kernel-source-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "kernel-tools-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "kernel-tools-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "kernel-tools-devel-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "perf-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "perf-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "python2-perf-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "python2-perf-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "python3-perf-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm", "python3-perf-debuginfo-4.19.90-2412.1.0.0306.oe2003sp4.aarch64.rpm" ] }