| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Inappropriate implementation in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High) |
| Interface exposure vulnerability in the mobile application (com.transsion.carlcare) may lead to information leakage risk. |
| Logical vulnerability in the mobile application (com.transsion.carlcare) may lead to user information leakage risks. |
| In the Linux kernel, the following vulnerability has been resolved:
tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT
This requirement was overeagerly loosened in commit 2f83e38a095f
("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), but as
it turns out,
(1) the logic I implemented there was inconsistent (apologies!),
(2) TIOCL_SELMOUSEREPORT might actually be a small security risk
after all, and
(3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse
daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN
already.
In more detail:
1. The previous patch has inconsistent logic:
In commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes
without CAP_SYS_ADMIN"), we checked for sel_mode ==
TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of
this "mode" parameter were actually used as an additional way to
pass an argument. So the patch did actually still require
CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not
require it if none of the mouse buttons bits are set.
This logic is inconsistent and was not intentional. We should have
the same policies for using TIOCL_SELMOUSEREPORT independent of the
value of the "hidden" mouse button argument.
I sent a separate documentation patch to the man page list with
more details on TIOCL_SELMOUSEREPORT:
https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/
2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can
let an attacker simulate "keyboard" input to command line
applications on the same terminal, like TIOCSTI and some other
TIOCLINUX "selection mode" IOCTLs.
By enabling mouse reporting on a terminal and then injecting mouse
reports through TIOCL_SELMOUSEREPORT, an attacker can simulate
mouse movements on the same terminal, similar to the TIOCSTI
keystroke injection attacks that were previously possible with
TIOCSTI and other TIOCL_SETSEL selection modes.
Many programs (including libreadline/bash) are then prone to
misinterpret these mouse reports as normal keyboard input because
they do not expect input in the X11 mouse protocol form. The
attacker does not have complete control over the escape sequence,
but they can at least control the values of two consecutive bytes
in the binary mouse reporting escape sequence.
I went into more detail on that in the discussion at
https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/
It is not equally trivial to simulate arbitrary keystrokes as it
was with TIOCSTI (commit 83efeeeb3d04 ("tty: Allow TIOCSTI to be
disabled")), but the general mechanism is there, and together with
the small number of existing legit use cases (see below), it would
be better to revert back to requiring CAP_SYS_ADMIN for
TIOCL_SELMOUSEREPORT, as it was already the case before
commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without
CAP_SYS_ADMIN").
3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or
Consolation), and they are the only legit use case:
To quote console_codes(4):
The mouse tracking facility is intended to return
xterm(1)-compatible mouse status reports. Because the console
driver has no way to know the device or type of the mouse, these
reports are returned in the console input stream only when the
virtual terminal driver receives a mouse update ioctl. These
ioctls must be generated by a mouse-aware user-mode application
such as the gpm(8) daemon.
Jared Finder has also confirmed in
https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/
that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it
would be difficult to find good reasons for doing that, given that
it would interfere with the reports that GPM is sending.
More information on the interaction between GPM, terminals and th
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration
Resolve kernel panic while accessing IRQ handler associated with the
generated IRQ. This is done by acquiring the spinlock and storing the
current interrupt state before handling the interrupt request using
generic_handle_irq.
A previous fix patch was submitted where 'generic_handle_irq' was
replaced with 'handle_nested_irq'. However, this change also causes
the kernel panic where after determining which GPIO triggered the
interrupt and attempting to call handle_nested_irq with the mapped
IRQ number, leads to a failure in locating the registered handler. |
| In the Linux kernel, the following vulnerability has been resolved:
mei: vsc: Fix fortify-panic caused by invalid counted_by() use
gcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[]
and the vsc-tp.c code is using this in a wrong way. len does not contain
the available size in the buffer, it contains the actual packet length
*without* the crc. So as soon as vsc_tp_xfer() tries to add the crc to
buf[] the fortify-panic handler gets triggered:
[ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0
[ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50
...
[ 80.843175] __fortify_panic+0x9/0xb
[ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw]
[ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90
[ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110
[ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc]
[ 80.843270] mei_reset+0x11d/0x420 [mei]
The easiest fix would be to just drop the counted-by but with the exception
of the ack buffer in vsc_tp_xfer_helper() which only contains enough room
for the packet-header, all other uses of vsc_tp_packet always use a buffer
of VSC_TP_MAX_XFER_SIZE bytes for the packet.
Instead of just dropping the counted-by, split the vsc_tp_packet struct
definition into a header and a full-packet definition and use a fixed
size buf[] in the packet definition, this way fortify-source buffer
overrun checking still works when enabled. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: don't replace page in rq_pages if it's a continuation of last page
The splice read calls nfsd_splice_actor to put the pages containing file
data into the svc_rqst->rq_pages array. It's possible however to get a
splice result that only has a partial page at the end, if (e.g.) the
filesystem hands back a short read that doesn't cover the whole page.
nfsd_splice_actor will plop the partial page into its rq_pages array and
return. Then later, when nfsd_splice_actor is called again, the
remainder of the page may end up being filled out. At this point,
nfsd_splice_actor will put the page into the array _again_ corrupting
the reply. If this is done enough times, rq_next_page will overrun the
array and corrupt the trailing fields -- the rq_respages and
rq_next_page pointers themselves.
If we've already added the page to the array in the last pass, don't add
it to the array a second time when dealing with a splice continuation.
This was originally handled properly in nfsd_splice_actor, but commit
91e23b1c3982 ("NFSD: Clean up nfsd_splice_actor()") removed the check
for it. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: connac: do not check WED status for non-mmio devices
WED is supported just for mmio devices, so do not check it for usb or
sdio devices. This patch fixes the crash reported below:
[ 21.946627] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d
[ 22.525298] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3)
[ 22.548274] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d
[ 22.557694] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3)
[ 22.565885] wlp0s3u1i3: authenticated
[ 22.569502] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 1/3)
[ 22.578966] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=30 aid=3)
[ 22.579113] wlp0s3u1i3: c4:41:1e:f5:2b:1d rejected association temporarily; comeback duration 1000 TU (1024 ms)
[ 23.649518] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 2/3)
[ 23.752528] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=0 aid=3)
[ 23.797450] wlp0s3u1i3: associated
[ 24.959527] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[ 24.959640] BUG: unable to handle page fault for address: ffff88800c223200
[ 24.959706] #PF: supervisor instruction fetch in kernel mode
[ 24.959788] #PF: error_code(0x0011) - permissions violation
[ 24.959846] PGD 2c01067 P4D 2c01067 PUD 2c02067 PMD c2a8063 PTE 800000000c223163
[ 24.959957] Oops: 0011 [#1] PREEMPT SMP
[ 24.960009] CPU: 0 PID: 391 Comm: wpa_supplicant Not tainted 6.2.0-kvm #18
[ 24.960089] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
[ 24.960191] RIP: 0010:0xffff88800c223200
[ 24.960446] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282
[ 24.960513] RAX: ffff888028397010 RBX: ffff88800c26e630 RCX: 0000000000000058
[ 24.960598] RDX: ffff88800c26f844 RSI: 0000000000000006 RDI: ffff888028397010
[ 24.960682] RBP: ffff88800ea72f00 R08: 18b873fbab2b964c R09: be06b38235f3c63c
[ 24.960766] R10: 18b873fbab2b964c R11: be06b38235f3c63c R12: 0000000000000001
[ 24.960853] R13: ffff88800c26f84c R14: ffff8880063f0ff8 R15: ffff88800c26e644
[ 24.960950] FS: 00007effcea327c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
[ 24.961036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 24.961106] CR2: ffff88800c223200 CR3: 000000000eaa2000 CR4: 00000000000006b0
[ 24.961190] Call Trace:
[ 24.961219] <TASK>
[ 24.961245] ? mt76_connac_mcu_add_key+0x2cf/0x310
[ 24.961313] ? mt7921_set_key+0x150/0x200
[ 24.961365] ? drv_set_key+0xa9/0x1b0
[ 24.961418] ? ieee80211_key_enable_hw_accel+0xd9/0x240
[ 24.961485] ? ieee80211_key_replace+0x3f3/0x730
[ 24.961541] ? crypto_shash_setkey+0x89/0xd0
[ 24.961597] ? ieee80211_key_link+0x2d7/0x3a0
[ 24.961664] ? crypto_aead_setauthsize+0x31/0x50
[ 24.961730] ? sta_info_hash_lookup+0xa6/0xf0
[ 24.961785] ? ieee80211_add_key+0x1fc/0x250
[ 24.961842] ? rdev_add_key+0x41/0x140
[ 24.961882] ? nl80211_parse_key+0x6c/0x2f0
[ 24.961940] ? nl80211_new_key+0x24a/0x290
[ 24.961984] ? genl_rcv_msg+0x36c/0x3a0
[ 24.962036] ? rdev_mod_link_station+0xe0/0xe0
[ 24.962102] ? nl80211_set_key+0x410/0x410
[ 24.962143] ? nl80211_pre_doit+0x200/0x200
[ 24.962187] ? genl_bind+0xc0/0xc0
[ 24.962217] ? netlink_rcv_skb+0xaa/0xd0
[ 24.962259] ? genl_rcv+0x24/0x40
[ 24.962300] ? netlink_unicast+0x224/0x2f0
[ 24.962345] ? netlink_sendmsg+0x30b/0x3d0
[ 24.962388] ? ____sys_sendmsg+0x109/0x1b0
[ 24.962388] ? ____sys_sendmsg+0x109/0x1b0
[ 24.962440] ? __import_iovec+0x2e/0x110
[ 24.962482] ? ___sys_sendmsg+0xbe/0xe0
[ 24.962525] ? mod_objcg_state+0x25c/0x330
[ 24.962576] ? __dentry_kill+0x19e/0x1d0
[ 24.962618] ? call_rcu+0x18f/0x270
[ 24.962660] ? __dentry_kill+0x19e/0x1d0
[ 24.962702] ? __x64_sys_sendmsg+0x70/0x90
[ 24.962744] ? do_syscall_64+0x3d/0x80
[ 24.962796] ? exit_to_user_mode_prepare+0x1b/0x70
[ 24.962852] ? entry_SYSCA
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915/active: Fix misuse of non-idle barriers as fence trackers
Users reported oopses on list corruptions when using i915 perf with a
number of concurrently running graphics applications. Root cause analysis
pointed at an issue in barrier processing code -- a race among perf open /
close replacing active barriers with perf requests on kernel context and
concurrent barrier preallocate / acquire operations performed during user
context first pin / last unpin.
When adding a request to a composite tracker, we try to reuse an existing
fence tracker, already allocated and registered with that composite. The
tracker we obtain may already track another fence, may be an idle barrier,
or an active barrier.
If the tracker we get occurs a non-idle barrier then we try to delete that
barrier from a list of barrier tasks it belongs to. However, while doing
that we don't respect return value from a function that performs the
barrier deletion. Should the deletion ever fail, we would end up reusing
the tracker still registered as a barrier task. Since the same structure
field is reused with both fence callback lists and barrier tasks list,
list corruptions would likely occur.
Barriers are now deleted from a barrier tasks list by temporarily removing
the list content, traversing that content with skip over the node to be
deleted, then populating the list back with the modified content. Should
that intentionally racy concurrent deletion attempts be not serialized,
one or more of those may fail because of the list being temporary empty.
Related code that ignores the results of barrier deletion was initially
introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the
idle-barrier from other kernel requests"). However, all users of the
barrier deletion routine were apparently serialized at that time, then the
issue didn't exhibit itself. Results of git bisect with help of a newly
developed igt@gem_barrier_race@remote-request IGT test indicate that list
corruptions might start to appear after commit 311770173fac ("drm/i915/gt:
Schedule request retirement when timeline idles"), introduced in v5.5.
Respect results of barrier deletion attempts -- mark the barrier as idle
only if successfully deleted from the list. Then, before proceeding with
setting our fence as the one currently tracked, make sure that the tracker
we've got is not a non-idle barrier. If that check fails then don't use
that tracker but go back and try to acquire a new, usable one.
v3: use unlikely() to document what outcome we expect (Andi),
- fix bad grammar in commit description.
v2: no code changes,
- blame commit 311770173fac ("drm/i915/gt: Schedule request retirement
when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow
sharing the idle-barrier from other kernel requests"), v5.4,
- reword commit description.
(cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7) |
| In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Only call get_timer_irq() once in constant_clockevent_init()
Under CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_DEBUG_PREEMPT=y, we can see
the following messages on LoongArch, this is because using might_sleep()
in preemption disable context.
[ 0.001127] smp: Bringing up secondary CPUs ...
[ 0.001222] Booting CPU#1...
[ 0.001244] 64-bit Loongson Processor probed (LA464 Core)
[ 0.001247] CPU1 revision is: 0014c012 (Loongson-64bit)
[ 0.001250] FPU1 revision is: 00000000
[ 0.001252] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283
[ 0.001255] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
[ 0.001257] preempt_count: 1, expected: 0
[ 0.001258] RCU nest depth: 0, expected: 0
[ 0.001259] Preemption disabled at:
[ 0.001261] [<9000000000223800>] arch_dup_task_struct+0x20/0x110
[ 0.001272] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc7+ #43
[ 0.001275] Hardware name: Loongson Loongson-3A5000-7A1000-1w-A2101/Loongson-LS3A5000-7A1000-1w-A2101, BIOS vUDK2018-LoongArch-V4.0.05132-beta10 12/13/202
[ 0.001277] Stack : 0072617764726148 0000000000000000 9000000000222f1c 90000001001e0000
[ 0.001286] 90000001001e3be0 90000001001e3be8 0000000000000000 0000000000000000
[ 0.001292] 90000001001e3be8 0000000000000040 90000001001e3cb8 90000001001e3a50
[ 0.001297] 9000000001642000 90000001001e3be8 be694d10ce4139dd 9000000100174500
[ 0.001303] 0000000000000001 0000000000000001 00000000ffffe0a2 0000000000000020
[ 0.001309] 000000000000002f 9000000001354116 00000000056b0000 ffffffffffffffff
[ 0.001314] 0000000000000000 0000000000000000 90000000014f6e90 9000000001642000
[ 0.001320] 900000000022b69c 0000000000000001 0000000000000000 9000000001736a90
[ 0.001325] 9000000100038000 0000000000000000 9000000000222f34 0000000000000000
[ 0.001331] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000
[ 0.001337] ...
[ 0.001339] Call Trace:
[ 0.001342] [<9000000000222f34>] show_stack+0x5c/0x180
[ 0.001346] [<90000000010bdd80>] dump_stack_lvl+0x60/0x88
[ 0.001352] [<9000000000266418>] __might_resched+0x180/0x1cc
[ 0.001356] [<90000000010c742c>] mutex_lock+0x20/0x64
[ 0.001359] [<90000000002a8ccc>] irq_find_matching_fwspec+0x48/0x124
[ 0.001364] [<90000000002259c4>] constant_clockevent_init+0x68/0x204
[ 0.001368] [<900000000022acf4>] start_secondary+0x40/0xa8
[ 0.001371] [<90000000010c0124>] smpboot_entry+0x60/0x64
Here are the complete call chains:
smpboot_entry()
start_secondary()
constant_clockevent_init()
get_timer_irq()
irq_find_matching_fwnode()
irq_find_matching_fwspec()
mutex_lock()
might_sleep()
__might_sleep()
__might_resched()
In order to avoid the above issue, we should break the call chains,
using timer_irq_installed variable as check condition to only call
get_timer_irq() once in constant_clockevent_init() is a simple and
proper way. |
| An attacker with a valid read-only account can bypass Doris MCP Server’s read-only mode due to improper access control, allowing modifications that should have been prevented by read-only restrictions.
Impact:
Bypasses read-only mode; attackers with read-only access may perform unauthorized modifications.
Recommended action for operators: Upgrade to version 0.6.0 as soon as possible (this release contains the fix). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini
The call trace occurs when the amdgpu is removed after
the mode1 reset. During mode1 reset, from suspend to resume,
there is no need to reinitialize the ta firmware buffer
which caused the bo pin_count increase redundantly.
[ 489.885525] Call Trace:
[ 489.885525] <TASK>
[ 489.885526] amdttm_bo_put+0x34/0x50 [amdttm]
[ 489.885529] amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu]
[ 489.885620] psp_free_shared_bufs+0xb7/0x150 [amdgpu]
[ 489.885720] psp_hw_fini+0xce/0x170 [amdgpu]
[ 489.885815] amdgpu_device_fini_hw+0x2ff/0x413 [amdgpu]
[ 489.885960] ? blocking_notifier_chain_unregister+0x56/0xb0
[ 489.885962] amdgpu_driver_unload_kms+0x51/0x60 [amdgpu]
[ 489.886049] amdgpu_pci_remove+0x5a/0x140 [amdgpu]
[ 489.886132] ? __pm_runtime_resume+0x60/0x90
[ 489.886134] pci_device_remove+0x3e/0xb0
[ 489.886135] __device_release_driver+0x1ab/0x2a0
[ 489.886137] driver_detach+0xf3/0x140
[ 489.886138] bus_remove_driver+0x6c/0xf0
[ 489.886140] driver_unregister+0x31/0x60
[ 489.886141] pci_unregister_driver+0x40/0x90
[ 489.886142] amdgpu_exit+0x15/0x451 [amdgpu] |
| In the Linux kernel, the following vulnerability has been resolved:
xsk: Add missing overflow check in xdp_umem_reg
The number of chunks can overflow u32. Make sure to return -EINVAL on
overflow. Also remove a redundant u32 cast assigning umem->npgs. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: prevent hang on link training fail
[Why]
When link training fails, the phy clock will be disabled. However, in
enable_streams, it is assumed that link training succeeded and the
mux selects the phy clock, causing a hang when a register write is made.
[How]
When enable_stream is hit, check if link training failed. If it did, fall
back to the ref clock to avoid a hang and keep the system in a recoverable
state. |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: inftlcore: Add error check for inftl_read_oob()
In INFTL_findwriteunit(), the return value of inftl_read_oob()
need to be checked. A proper implementation can be
found in INFTL_deleteblock(). The status will be set as
SECTOR_IGNORE to break from the while-loop correctly
if the inftl_read_oob() fails. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Silence oversized kvmalloc() warning
syzkaller triggered an oversized kvmalloc() warning.
Silence it by adding __GFP_NOWARN.
syzkaller log:
WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180
CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:__kvmalloc_node_noprof+0x175/0x180
RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246
RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b
RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002
RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000
R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000
R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000
FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ib_umem_odp_get+0x1f6/0x390
mlx5_ib_reg_user_mr+0x1e8/0x450
ib_uverbs_reg_mr+0x28b/0x440
ib_uverbs_write+0x7d3/0xa30
vfs_write+0x1ac/0x6c0
ksys_write+0x134/0x170
? __sanitizer_cov_trace_pc+0x1c/0x50
do_syscall_64+0x50/0x110
entry_SYSCALL_64_after_hwframe+0x76/0x7e |
| In the Linux kernel, the following vulnerability has been resolved:
mlxbf-bootctl: use sysfs_emit_at() in secure_boot_fuse_state_show()
A warning is seen when running the latest kernel on a BlueField SOC:
[251.512704] ------------[ cut here ]------------
[251.512711] invalid sysfs_emit: buf:0000000003aa32ae
[251.512720] WARNING: CPU: 1 PID: 705264 at fs/sysfs/file.c:767 sysfs_emit+0xac/0xc8
The warning is triggered because the mlxbf-bootctl driver invokes
"sysfs_emit()" with a buffer pointer that is not aligned to the
start of the page. The driver should instead use "sysfs_emit_at()"
to support non-zero offsets into the destination buffer. |
| In the Linux kernel, the following vulnerability has been resolved:
ovl: don't allow datadir only
In theory overlayfs could support upper layer directly referring to a data
layer, but there's no current use case for this.
Originally, when data-only layers were introduced, this wasn't allowed,
only introduced by the "datadir+" feature, but without actually handling
this case, resulting in an Oops.
Fix by disallowing datadir without lowerdir. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: harden block_group::bg_list against list_del() races
As far as I can tell, these calls of list_del_init() on bg_list cannot
run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),
as they are in transaction error paths and situations where the block
group is readonly.
However, if there is any chance at all of racing with mark_bg_unused(),
or a different future user of bg_list, better to be safe than sorry.
Otherwise we risk the following interleaving (bg_list refcount in parens)
T1 (some random op) T2 (btrfs_mark_bg_unused)
!list_empty(&bg->bg_list); (1)
list_del_init(&bg->bg_list); (1)
list_move_tail (1)
btrfs_put_block_group (0)
btrfs_delete_unused_bgs
bg = list_first_entry
list_del_init(&bg->bg_list);
btrfs_put_block_group(bg); (-1)
Ultimately, this results in a broken ref count that hits zero one deref
early and the real final deref underflows the refcount, resulting in a WARNING. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu: Clear iommu-dma ops on cleanup
If iommu_device_register() encounters an error, it can end up tearing
down already-configured groups and default domains, however this
currently still leaves devices hooked up to iommu-dma (and even
historically the behaviour in this area was at best inconsistent across
architectures/drivers...) Although in the case that an IOMMU is present
whose driver has failed to probe, users cannot necessarily expect DMA to
work anyway, it's still arguable that we should do our best to put
things back as if the IOMMU driver was never there at all, and certainly
the potential for crashing in iommu-dma itself is undesirable. Make sure
we clean up the dev->dma_iommu flag along with everything else. |
